Блог

Итак, я пытаюсь отобразить значимые и точные коды состояния HTTP, и я запутываюсь даже после просмотра примеров в Интернете. Вот моя ситуация:

В URL-адресе, который принимает параметр запроса:

 @POST query
Sample URL: /putRecord?Name=Aamp;Age=25amp;house=permanent
  

1. какой код состояния мне возвращать, если один из параметров отсутствует? (Все 3 являются обязательными) — из того, что я прочитал, я предполагаю, что это 400: неверный запрос. Но это кажется слишком общим. Есть ли у меня способ сказать, что запрос был неверно сформирован? Источник: здесь
2. Предполагая, что я проверяю имя на наличие дубликатов в базе данных, если я получу дубликат, какой код состояния я верну?

3. Итак, если уже есть дублирующая запись, я не могу добавить запись. Должен ли я отображать 304 (не измененный) или просто код ошибки из 2? Уточнение: для 3 другая возможность заключается в том, что я не могу фактически зафиксировать данные в БД и выполнить откат (возможно). Какой код состояния будет теперь?

   Большое спасибо!

Объявление 1. Вы можете вернуть, помимо самого кода (400), также короткое сообщение с объяснением. Итак, вместо того, чтобы повторять «400 неверных запросов», вы могли бы ответить «требуется имя параметра запроса 400» или что-то подобное. Это сообщение называется «фраза причины» и определено в 6.1 в RFC 2616. Или, если вам нужно больше гибкости, вы можете вернуть document с объяснением.

Объявление 2. Я бы подумал об использовании 422 необработанных объектов. Из RFC 4918:

Код состояния 422 (необработанный объект) означает, что сервер понимает тип содержимого объекта запроса, и синтаксис объекта запроса правильный (таким образом, код состояния 400 (неверный запрос) неуместен), но не смог обработать содержащиеся инструкции.

Объявление 3. Я бы вернул 422, но это действительно зависит от того, считается ли эта ситуация ошибкой в вашей логике или это обычная, ожидаемая ситуация.

Редактировать: как @War10ck предложил в комментарии, HTTP 409 (вместо HTTP 422) также может иметь смысл.

Примечание по обработке дубликатов: кажется (поправьте меня, если я ошибаюсь), что вы считаете, что new entity является дубликатом, если его имя уже есть в базе данных. Если да, то, возможно, вы могли бы рассмотреть возможность использования HTTP PUT вместо HTTP POST?

Вы могли бы определить следующий ресурс:

 HTTP PUT /record/:name
  

Итак, «имя» будет частью URI. Затем, в случае, если на тот же ресурс (с тем же «именем») будет отправлен второй запрос, было бы элегантно ответить 409/422.

Если вы используете другой ключ для ограничения уникальности, измените URI соответствующим образом.

Как правило, POST предназначен для ситуаций, когда у вас может быть несколько экземпляров данного ресурса, т. Е.

 HTTP POST /log  ;; Because we have many logs
  

И СТАВЬТЕ для ситуаций, когда каждый ресурс уникален:

 HTTP PUT /person/:name (or /person/:tax-number if :name isn't unique)
  

Кроме того, обратите внимание, что я переименовал ваш ресурс из «PutRecord» в «record» — PUT — это HTTP-метод, нет причин также указывать его в URI.