REST: правильный статус ответа в соответствии со спецификацией RFC 2616 HTTP/1.1?

Я просмотрел спецификацию протокола HTTP/1.1 в RFC-2616 и я пытаюсь понять, какой код состояния должен быть возвращен при вызове определенного метода REST. Насколько я изучил протокол (ссылки), я пытался разобрать методы REST на правильный код состояния:

  • GET
    • to return 200 (ok) in case at least one resource is found.
    • должен ли я возвращать 204 (не найдено), если ничего не найдено (т.е. возвращается пустой список)?
  • PUT
  • POST
    • the same like PUT method with the difference the 201 (created) is returned if the new reource has been added to the orign
    • на основе общей рекомендации, POST следует использовать для создания нового ресурса, PUT для изменения существующий. Если я решу следовать этой рекомендации, что я должен вернуть в случае попытки изменить существующий ресурс ex. POST api/v1/person/1?
  • PATCH
    • the same like PUT method with the difference it doesn't replace the whole resource like PUT does, but itmodifies a resource partially
    • в протоколе W3 RFC-2616 нет ни слова о методе PATCH REST, следует относиться к нему так же, как PUT?
  • DELETE
    • to return 200 (ok) if the resource was deleted and [204 (not found)] in case there is no resource existing to remove (id not found). Does it copy the GET responses principe in case of REST implementation?

Правильно ли моя «таблица» (особенно утверждения с кавычками ?? Правильно ли, что только GET должен возвращать сам запрос в теле, а остальные методы просто ссылку URI на измененный ресурс (новый добавленный, измененный..) включено в шапку?

Правильно ли я понимаю, и существует ли другой источник, официально описывающий методы REST, которому рекомендуется (или мы «обязаны») следовать? Меня очень смущает широкий спектр источников, дающих мне немного разные ответы на каждый метод, а также этот действительно подробный RFC-2616.

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


person Nikolas Charalambidis    schedule 02.09.2017    source источник
comment
Попытка согласовать коды состояния с методами, вероятно, не является полезной идеей.   -  person VoiceOfUnreason    schedule 02.09.2017
comment
https://www.iana.org/assignments/http-methods/http-methods.xhtml содержит ссылки на определения методов.   -  person Julian Reschke    schedule 03.09.2017


Ответы (1)


Из RFC 7230

Эта спецификация HTTP/1.1 отменяет RFC 2616.

Таким образом, любая попытка разработать шаблоны для кодов состояния должна начинаться с этого.

Моя "таблица" правильная

Не совсем; взгляните на блок-схемы Кропата (неофициальные) в Хватит усложнять.

person VoiceOfUnreason    schedule 02.09.2017
comment
Возможно, стоит отметить: учитывая, что текущая спецификация HTTP/1.1 состоит из нескольких частей, RFC 7231 Semantics and Content инструменты .ietf.org/html/rfc7231 также отменяет RFC 2616 и является конкретной частью, в которой теперь определяется семантика кодов состояния. - person sideshowbarker; 03.09.2017
comment
Ссылка со временем изменилась: https://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html - person Nikolas Charalambidis; 21.02.2020