Могу ли я придумать свой собственный код статуса HTTP для случая, когда сущность обновляется, а сервер возвращает представление обновленной сущности?

Question

Примечание Bene

Я думал, что это будет очевидным, учитывая, что www.restapitutorial.com это не , вНа самом деле, веб-сайт органа по стандартизации, отвечающий за коды статуса HTTP, а скорее просто удобный веб-сайт с лучшим пользовательским интерфейсом, чем у www.iana.org или www.ietf.org .

Очевидно, это было ошибочное предположение с моей стороны.Так что в духе науки, если вы так долго любите синие, курьерские и страничные свитки по умолчанию, что вам нужно взять с собой ланч, посмотрите www.iana.org .Или, если у вас также есть фетиш для неработающих ссылок на изображения, вы можете найти (вероятно) точно такую ​​же информацию, представленную на www.ietf.org .

В противном случае я нашел www.restapitutorial.com - очень удобный веб-сайт с точной информацией, представленной таким образом, что это просто приятное маленькое наслаждение в холодный и снежный февральский день.

Это сводит меня с ума, что официальный HTTP Status Codes Spec кажется , чтобы покрыть все сценарии, с которыми можно столкнуться, но имеет действительно неудачные и шаткие варианты для любоготип UPDATE/PATCH запроса, который ваша система должна обработать.

Опции (Отсутствие)

200 OK
КЛИЕНТ: "Эй, сервер,что случилось с той просьбой, которую я только что тебе отправил?
СЕРВЕР: «Ничего плохого!»

Это настолько расплывчато, что опасно бесполезно.Для клиента, для системы, для регистрации, для аналитики, для всего Интернета.Но это единственная опция, которую я нашел для UPDATE, которая фактически возвращает представление обновленного ресурса.

202 Принято
КЛИЕНТ: «Эй, сервер, что случилось с тем запросом, который я только что отправил тебе?»
СЕРВЕР: «Я получил его."

Опять, может быть, немного подробнее здесь?Понятно, что это может быть использовано для долгосрочных задач в качестве одобрения клиента, когда он сначала отправляет долгосрочную задачу, но затем, когда долгосрочная задача завершена, мы возвращаемся к стандартному значению 200 OK.Но опять же, бесполезно для «стандартного» ОБНОВЛЕНИЯ (например, обновление биографии вашего аккаунта).

204 Нет содержимого
КЛИЕНТ: «Эй, сервер, каков статус того запроса на обновление, который я только что отправил?»
СЕРВЕР: «Я получилэто, и полностью сделал обновление. Вы также должны обновить сущность на своем конце. "
КЛИЕНТ:" Отлично! Но вы не отправили сущность до конца в своем ответе. "
СЕРВЕР:" Конечно, нетМне это не нужно. Я оставил вам подсказку в заголовках. "
КЛИЕНТ:" Хорошо? Тогда я могу посмотреть в заголовках вашего ответа и получить метаинформацию, необходимую для отправки другого просит вас получить обновленную сущность? Похоже, вы могли только что отправить мне обновленную сущность. "
SERVER:" Мне больше нечего сказать по этому вопросу. "

Я имею в виду, на сервере была обновленная сущность прямо там .Почему незаконно отправлять его обратно как основную часть ответа?Опять же, бесполезно для простого запроса ОБНОВЛЕНИЕ.

205 Сбросить содержимое
КЛИЕНТ: «Эй, сервер, каков статус отправленного мной запроса ОБНОВЛЕНИЯ?»
СЕРВЕР: «Я получил этои я полностью сделал обновление. Вы должны обновить его и на своем конце. "
КЛИЕНТ:" Круто! Но вы не отправили обновленную сущность обратно мне? "
СЕРВЕР:" Конечно, нет, этонезаконно! "
КЛИЕНТ:" Действительно? Потому что кажется, что вы можете легко прикрепить обновленную сущность к телу вашего ответа, и тогда мне не нужно отправлять еще один запрос только для того, чтобы получитьобновленный объект. "

И это все.Ни один из них не полезен для полного описания успешного результата био ОБНОВЛЕНИЕ и возвращенного обновленного объекта.

Вопросы

• Итак, я могу просто создать свой собственный код статуса HTTP?
• 209 Entity Обновлено? Кажется, что числовой код доступен .
• Это, очевидно, не очень "безопасно" в отношении того, как различные клиенты (браузеры, SDK и т. Д.) Имеют встроенные правила дляобработка кодов состояния.
• Кто-нибудь еще делал это?
• Я знаю, что Твиттер возвращает их супер-хип 420 Enhance Your Calm.Мы все очень впечатлены их остроумием, и это, кажется, не сломало интернет.Но это также «редкий» код ошибки, используемый для ограничения скорости, а не типичный код успеха.
• Каковы ошибки, которые идут вместе с раскрашиванием за пределы официальных HTTP-кодов состояния Spec ?

Answer 1

Вам, наверное, нужно немного переосмыслить здесь.Коды состояния HTTP не выражают ответы бизнес-логики , они с точки зрения протокола HTTP .200 OK означает, что сервер выполнил запрос, который вы передали ему в соответствии с запросом.Это целенаправленно, поскольку запрос может быть одним из практически бесконечного числа запросов бизнес-логики.Не может быть уникального кода для каждого возможного вида запроса или действия, предпринимаемого сервером, поскольку он уникален для каждого приложения.

Если вы запросили сервер обновить некоторые данные с помощью запроса PUT, то 200 OK означает «Я успешно обновил эти данные в соответствии с запросом».Там нет особой необходимости дифференцировать это с более конкретным кодом.Предположительно, вы знаете, что запрашивали у сервера, а 200 OK означает, что запрос был выполнен.

Более конкретные 2xx существующие коды выражают нечто уникальное с точки зрения HTTP .201 Created означает, что теперь доступен новый ресурс с новым URI, и этот URI был возвращен в заголовке Location.202 Accepted означает, что сервер (вероятно) выполнит ваш запрос, но еще не выполнил, поэтому в данный момент для вас нет нового ресурса, и / или изменения еще не отражены в текущем ресурсе.204 No Content означает, что сервер выполнил ваш запрос, но ответ не содержит никаких данных тела, и, следовательно, клиент не должен / не должен каким-либо образом обрабатывать тело ответа.

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

Чтобы взломать этот дом, сервер может ответить на запрос DELETE /user/42 с помощью 201 Created;Это имеет смысл, если удаление может занять некоторое время, и теперь для вас есть новый URI, где вы можете проверить состояние этой операции.201 Created не означает «новый пользователь был создан», это означает «запрос был принят (потому что он находится в диапазоне 2xx), и существует новый ресурс HTTP в отношении этого запроса, которыйВы можете проверить. ”

Answer 2

Прежде всего, список доверенных кодов состояния - это один из IANA (а не тот, который вы использовали в своем вопросе).

Теперь вернемся к вашему вопросу ..Как только HTTP-коды состояния расширяются, вы можете создать новый код состояния.Но это не означает, что вы должны .

---

Код состояния предназначен для описания результата попытки сервера понять и удовлетворить соответствующий запрос клиента.Код состояния 200, определенный в RFC 7231 и приведенный ниже, охватывает сценарий, который вы описали в своем вопросе.Для этой цели нет необходимости определять другой код состояния.

6.3.1.200 OK

Код состояния 200 (OK) указывает, что запрос выполнен успешно.Полезная нагрузка, отправляемая в ответе 200, зависит от метода запроса.Для методов, определенных в настоящей спецификации, предполагаемое значение полезной нагрузки может быть суммировано как:

• GET: представление целевого ресурса;

• HEAD: то же представление, что и GET, но без данных представления;

• POST: представление статуса или результатов, полученных из,действие;

• PUT, DELETE: представление статуса действия;

• OPTIONS: представлениеиз вариантов связи;

• TRACE: представление сообщения запроса, полученного конечным сервером.

Сейчасобратитесь к разделу RFC 7231 , который описывает семантику метода PUT:

Если целевой ресурс не имеет текущего представленияи PUT успешно создает его, тогда сервер происхождения ДОЛЖЕН проинформировать агента пользователя, отправив 201 (Crсъел) ответ.Если целевой ресурс действительно имеет текущее представление и это представление успешно изменено в соответствии с состоянием вложенного представления, то сервер-источник ДОЛЖЕН отправить ответ 200 (OK) или 204 (без содержимого) науказывают на успешное завершение запроса.

Аналогичным образом, 200 также подходит как результат PATCH запросов, которые возвращают представлениеза ресурс, который был исправлен.

Если клиенту не требуется представление измененного ресурса, верните 204.

---

Для оптимального решения , вы можете разрешить клиенту решать, требуется ли представление.Для этой цели вы можете использовать заголовок Prefer, определенный в RFC 7240 с предпочтением return, где значение может быть либо representation или minimal:

4.2.Предпочтения «return = представление» и «return = минимальный»

Предпочтение return=representation указывает, что клиент предпочитает, чтобы сервер включал объект, представляющий текущее состояние ресурса вответ на успешный запрос.

Предпочтение return=minimal, с другой стороны, указывает, что клиент желает, чтобы сервер возвратил только минимальный ответ на успешный запрос.Как правило, такие ответы будут использовать статус 204 (без содержимого), но другие коды МОГУТ использоваться соответствующим образом, например, статус 200 (ОК) с объектом ответа нулевой длины.Определение того, что составляет соответствующий минимальный ответ, осуществляется исключительно по усмотрению сервера.

---

^{Примечание: Новые коды состояния должны следовать за требования , описанные в RFC 7231 .}