Ответ на идемпотентный HTTP-запрос POST

Question

Часть нашего RESTful API позволит пользователям зарегистрировать элемент с серийным номером.Поскольку серийный номер не является глобально уникальным, его нельзя использовать в качестве идентификатора ресурса, поэтому мы будем использовать POST для родительского ресурса, который сгенерирует идентификатор, например,

POST /my/items

<item serial-number="ABCDEF" />

В случае, когдаэлемент еще не зарегистрирован, семантика HTTP четко определена.Мы возвращаем заголовок Location и зарегистрированный элемент в качестве тела объекта, например

HTTP 201 Created
Location: /my/items/1234    

<item id="1234" serial-number="ABCDEF" />

Однако в случае, когда элемент уже зарегистрирован, API должен быть идемпотентным и возвращать ранее зарегистрированный элемент без созданияновенький.Мое лучшее предположение состоит в том, что он должен затем вернуть код состояния 200 OK и использовать заголовок Content-Location, чтобы указать, откуда на самом деле пришел элемент, например,

HTTP 200 OK
Content-Location: /my/items/1234    

<item id="1234" serial-number="ABCDEF" />

Было бы это разумным?Мне не совсем понятно, подходит ли Location или Content-Location во втором случае.

Answer 1

У меня недавно было похожее требование.Для идемпотентных операций PUT - лучший способ.Вы правы, есть несоответствие между внешним идентификатором и внутренним идентификатором.Я решил это, создав выделенный ресурс для внешнего целевого идентификатора:

PUT /api-user/{username}/items/{serialNumber}

Внутренне я разрешаю его как CREATE в случае, если у меня нет элемента для «username» и «ABCDEF», серийного номера или UPDATE в случаеЯ делаю.

В случае, если это был CREATE, я возвращаю 201 для ОБНОВЛЕНИЯ 200. Более того, возвращаемая полезная нагрузка содержит как внутренний доменный идентификатор, так и внешний серийный номер, как вы предложили в своей полезной нагрузке.

Answer 2

Здесь - интересное обсуждение использования двух заголовков.Он утверждает, что Content-Location не определен для PUT или POST, так что Location, возможно, является лучшим вариантом в вашем случае.Это, конечно, не совсем ясно, что лучше, хотя.

В целом, я думаю, что ваш подход имеет смысл, хотя.