HTTP-код для возврата для неподдерживаемого PATCH - PullRequest
0 голосов
/ 19 октября 2018

Я реализую метод PATCH для ресурса REST dropwizard.В настоящее время только часть свойств ресурса может быть исправлена.И в настоящее время может быть выполнена только операция замены.

Какой HTTP-код я должен вернуть, если у меня появляется запрос PATCH для свойства / пути, который не поддерживается?И что я должен вернуть, если запрошены неподдерживаемые операции add или remove?

Ответы [ 2 ]

0 голосов
/ 19 октября 2018

Мой голос будет 405:

405 Метод не разрешен

Метод запроса не поддерживается для запрошенного ресурса;например, запрос GET для формы, которая требует представления данных через POST, или запрос PUT для ресурса, доступного только для чтения.

В сочетании с предложением, которое Кассио делает относительно предоставления достаточной информации дляопишите ошибку.

0 голосов
/ 19 октября 2018

Какой HTTP-код мне следует вернуть, если я вижу PATCH запрос на свойство / путь, который не поддерживается?

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

6.5.5.405 Метод не разрешен

Код состояния 405 (метод не разрешен) указывает, что метод, полученный в строке запроса, известен серверу происхождения, но не поддерживается целевым ресурсом,Исходный сервер ДОЛЖЕН сгенерировать поле заголовка Allow в ответе 405, содержащем список поддерживаемых в настоящее время методов целевого ресурса.


И что я должен вернуть, еслизапрашиваются неподдерживаемые операции add или remove?

Полагаю, вы имеете в виду операции add и remove из JSONПатч , документ JSON, который описывает последовательность операций для применения к документу JSON и подходит для использования с методом PATCH HTTP.

Итак, посмотрите на ошибку обработка раздела RFC 5789 , документа, который определяет метод PATCH HTTP.

Ситуация, описанная в вашем вопросе, на самом деле является сущностью, которая не может быть обработана сервером по семантическим причинам.Так что 422 является разумным выбором, в соответствии с RFC 5789 :

необработанный запрос: Может быть указан с помощью422 (Unprocessable Entity) ответ, когда сервер понимает документ исправления, и синтаксис документа исправления представляется действительным, но сервер не способен обработать запрос.Это может включать попытки изменить ресурс таким образом, чтобы ресурс стал недействительным;например, модификация правильно сформированного XML-документа, которая больше не будет правильно формироваться.[...]

Также имейте в виду следующую рекомендацию из того же документа:

Тело ответов об ошибках ДОЛЖНО содержать достаточно информации, чтобы сообщить природуошибка клиенту.Тип содержимого объекта ответа может различаться в разных реализациях.

RFC 7807 определяет форматы документов, которые можно использовать для сообщения о проблемах в HTTP-API.

...