Я разрабатываю конечную точку API, которая использует естественные ключи в качестве идентификаторов ресурсов.
PUT /api/thing/key
GET /api/thing/key
etc.
Моя служба предоставляет операцию обновления (...), которая может привести к запросу SQL UPDATE, который может измениться этот ключ, т. е.
void Update(key, newRow);
При использовании неизменяемых суррогатных ключей вместо этого у меня было
void Update(key, newRowExceptKey);
, но поскольку теперь newData может содержать ключ, в результате ресурс может быть перемещен.
Допустимо ли отвечать на PUT с 201 и заголовком Location для нового ресурса? Это нормально для запросов POST, но кажется противоположным PUT. PUT с новым ключом фактически приводит к УДАЛЕНИЮ (с точки зрения состояния сервера) в URI запроса и PUT / POST для некоторого другого URI.
С другой стороны, возможно, мне не следует использовать PUT совсем. RF C 2616 говорит, что «URI в запросе PUT идентифицирует объект, заключенный в запрос». В реляционных терминах, если новый ключ не соответствует старому ключу, тогда URI запроса не идентифицирует вложенный ресурс. Но это не так просто. Прилагаемый ресурс является заменой для URI запроса, поэтому в некотором контексте (в частности, в том, что дополнено суррогатным ключом), URI идентифицирует вложенную сущность.
Я мог бы просто использовать здесь POST, поскольку это не кажется, нарушают какие-либо правила, но использование POST везде кажется быстрым и свободным.