Существует ли максимальная длина сообщения с кодом состояния HTTP?

#javascript #json #rest #http-status-codes

#javascript #json #остальное #http-status-codes

Вопрос:

Я работаю над проектом, в котором я создаю интерфейс, а кто-то другой создает API. Я предлагал следующую структуру для всех запросов, отправляемых в формате JSON:

 {
  "success": true, // true/false
  "message": null, // a string if success==false indicating the error
  "data": {} // The actual data in the response
}

Они больше заинтересованы в том, чтобы сделать API более RESTful, и вместо поля «сообщение» они предлагают отправить сообщение обратно в сообщении с кодом состояния, в заголовках HTTP, например:

 HTTP/1.1 401 Authentication Failed for john.smith@example.com. Please log in again.

и интерфейс отобразил бы «Ошибка аутентификации для john.smith@example.com . Пожалуйста, войдите снова «. во всплывающем окне или что-то в этом роде.

Меня беспокоят ограничения по длине, но я не смог найти ничего, что указывало бы на отсутствие максимальной длины. Должны ли мы гарантировать, что мы сохраняем эти сообщения минимальной длины? Есть ли веская причина не делать этого и вместо этого отправлять его обратно в виде содержимого (JSON или обычного текста)?

Ответ №1:

Небольшое тестирование будет иметь большое значение, но вы должны быть в порядке, чтобы сделать это, и на самом деле в RFC конкретно говорится:

Приведенные здесь фразы о причинах являются только рекомендациями — они МОГУТ быть заменены локальными эквивалентами без влияния на протокол.

Единственное, что вас может беспокоить, это размер заголовка (некоторые серверы могут иметь ограничения, но я думаю, что все они относительно большие) и то, как некоторые старые браузеры могут реагировать на это. Честно говоря, я думаю, что имеет смысл использовать тело ответа, поскольку его легче интерпретировать и прояснить, но в вашем подходе не должно быть ничего плохого.

1. К вашему сведению, RFC 2616 был заменен в прошлом месяце RFC 7231 через 7235. RFC 7230 определяет требования к длине для различных элементов, но не reason-phrase в ответе о состоянии.

Ответ №2:

Я хочу добавить, что, хотя в спецификации может не быть ограничений, существует реальная вероятность того, что реализации усекут сообщение о состоянии, как я обнаружил, когда я пробовал что-то похожее на OP с Jetty 9.4.14 .

Мне потребовалось некоторое время, чтобы найти причину усеченного сообщения — существует жестко закодированное, не настраиваемое ограничение в 1024 символа [см. Метод getReasonBytes(строка)].

(не удалось опубликовать это в качестве комментария из-за отсутствия репутации)