Код ответа HTTP при сбое создания ресурсов POST из-за существующего сопоставимого ресурса

Представьте, что у нас есть API, где новый Сотрудник может быть создан через POST для

www.example.com/api/employees

Сотрудник может быть описан как

{
  name: "John Smith",
  tax_number: "ABC123"
}

Номер налога является универсальным для всех людей. Если было создано создание, и уже существовала запись, в которой имя и номер налога соответствовали существующей записи, можно с уверенностью предположить, что запросчик хотел бы получить ссылку на эту запись (с ее внутренним идентификатором и другими данными, которые клиент может не есть, например, созданные, обновленные в).

Каков будет код статуса HTTP для возврата этого ресурса? Я предполагаю, что перенаправление может быть использовано с возвратом только идентификатора, но я предпочел бы заключить весь объект в ответ.

Этот случай уникален для простой повторяющейся ошибки в том смысле, что при попытке дублирования это означает, что запись, которую вы хотите создать, уже существует, а не противоречит существующей записи.

Ответ 1

Я думаю, что если вы отправляете ресурс в API, вы ожидаете, что код 201 будет указывать на то, что ресурс был создан, и тело будет (может) содержать ресурс. В противном случае вам сначала нужно проверить, создан ли ресурс, но для этого потребуется два вызова.

в противном случае у вас есть код состояния 409:

Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.

[Edit] после чтения в Restfull Web Apis от amundsen, Ruby и Richardson

Лучше всего использовать код состояния 409, в котором указывается, что существует конфликт с ресурсом, существующим на сервере. Поместите URL-адрес этого "конфликтного" ресурса в заголовке местоположения ответа и добавьте сообщение о конфликте в теле

Ответ 2

Существует код ответа 409 Conflict, который обычно используется, чтобы сообщить клиенту, что такой объект уже существует на сервере. Это может быть не очень интуитивно понятным, чтобы анализировать тело ответа об ошибке, но если вы укажете это в документации по API, не должно быть проблемы (чтобы поместить информацию об исходной записи в тело ответа).