Подразумевает ли ответ HTTP 200, что должно быть тело ответа? - PullRequest
Новая
       22

Подразумевает ли ответ HTTP 200, что должно быть тело ответа?

0 голосов
/ 11 июля 2020

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

/feature:
  get:
    summary: Returns all features
    operationId: getAllFeatures
    tags:
      - feature
    responses:
      '200':
        description: 'Features retrieved successfully'
      '400':
        $ref: '#/responses/BadRequest'

На основе сводки конечной точки и описания ответа 200 мне довольно ясно, что эта конечная точка была предназначена для возврата тела ответа, содержащего массив или коллекцию " feature ", хотя ответ не определен в spe c.

Предположим, что я прав, и автор spe c просто забыл добавить его. Что тогда мне следует делать с этой конечной точкой: 

/features:
  put:
    summary: Updates an existing feature
    operationId: updateFeature
    parameters:
      - name: body
        in: body
        description: 'Feature to be updated'
        required: true
        schema:
          $ref: '#/definitions/Feature'
    tags:
      - feature
    responses:
      '200':
        description: 'Feature updated'

Это неоднозначно для меня. Я видел некоторые реализации конечных точек обновления, которые возвращают обновленный объект. Другие, которые я видел, ничего не возвращают в теле.

Мои вопросы таковы:

  1. Подразумевает ли ответ HTTP 200, что должен быть телом ответа? Я не могу сказать, требует ли спецификация HTTP (https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) это или же там просто указано, что может быть там.
  2. Будет ли в этом сценарии менее запутанным, если автор spe c использовал HTTP 204, чтобы явно указать, что нет тела ответа? (Я могу ответить на этот вопрос - да - но есть ли причины использовать HTTP 200 вместо 204 в этом случае? Или это просто автор не знал о кодах успешного ответа, кроме HTTP 200?)
  3. Если ответ на # 1 - нет, а ответ на # 2 - да: почему HTTP был определен таким образом?

1 Ответ

2 голосов
/ 11 июля 2020
  1. 200 OK может возвращать пустое тело с Content-Length: 0.
  2. 204 No Content имеет более конкретную цель c, чем многие думают. Цитата из current spe c:

Ответ 204 позволяет серверу указать, что действие было успешно применено к целевому ресурсу, подразумевая при этом, что агенту пользователя не нужно уходить от своего текущего «представления документа» (если есть). Сервер предполагает, что пользовательский агент предоставит некоторый индикатор успеха своему пользователю в соответствии со своим собственным интерфейсом и применит любые новые или обновленные метаданные в ответе на свое активное представление.

В основном это означает, что если, например, отправлена ​​форма HTML, и сервер отвечает 204, он может сигнализировать браузеру не refre sh текущей страницы в новое место, или перенаправить куда-нибудь еще. Например, он может облегчить действие «сохранить», не заставляя браузер перенаправлять / переключаться на новый URL-адрес. Также см. 205 для аналогичного действия, но с другим поведением.

Браузеры (насколько мне известно) на самом деле не реализуют это поведение. Но клиент REST / Hypermedia / HATEOAS мог бы .

Текущий SPE c также указывает более распространенное использование, то есть 200 without a response body, но если вы go полностью вернемся к HTTP / 1.0 spe c, это весь раздел . Обратите внимание, что только упоминает это поведение и ничего не говорит о том, что 204 является просто заменой 200 минус тело:

Сервер выполнил запрос, но новых нет. информация для отправки. Если клиент является пользовательским агентом, он не должен изменять вид документа по сравнению с тем, который вызвал создание запроса. Этот ответ в первую очередь предназначен для того, чтобы разрешить ввод сценариев или других действий, не вызывая изменения в активном представлении документа пользовательского агента. Ответ может включать в себя новую метаинформацию в виде заголовков объектов, которые должны применяться к документу, который в настоящее время находится в активном представлении пользовательского агента. . удалив это, я согласен, что не так много причин использовать 204. Это стало условностью, которая, как мне кажется, не имеет особой цели.

Примечание: не обращайтесь к RFC2616, если только вы не занимаетесь rnet археологией.

См. # 2
...