Comments 4
А как обстоят дела с HTTP версий 2 и 3? Или это ждать в новых частях статьи?
Автор статьи преследует благие цели, но сама статья местами вводит в заблуждение.
Протокол не сохраняет состояние между запросами. Когда поступают два соседних запроса, сервер не понимает, от одного и того же клиента они поступили, или от разных.
Видимо имелось в виду, что сам протокол не обязывает передавать идентификаторы сессий и не обязывает хранить некое состояние, привязанное к клиенту. Потому как чуть менее чем всегда приложения могут менять состояние и могут отличить одного клиента от другого.
HTTP/1.0
В имени раздела упомянута версия 1.0 (почему не 1.1?), но в описании идет речь уже об 1.1. Потому как указанные в примерах заголовки и query string появились в версии 1.1.
201 Created ... Обычно он присылается в ответ на PUT запрос.
Это зависит от соглашений, принятых в конкретной команде. Вообще создание ресурсов делают через POST, а изменение через PUT / PATCH.
Query String. Это параметры формата ключ=значение
Формат query string никак не специфицирован протоколом. Большинство серверов сейчас разбирают по аналогии с x-ww-form-urlencoded, но на заре веба можно было встретить строки запроса с другими разделителями (; например).
Описанную проблему решает специальный заголовок
Content-Length. Он указывает на длину контента в байтах.
Если тело формируется динамически, никакого размера мы не узнаем. Тут вступает в игру Transfer-Encoding. Плюс само тело может быть не целостным, а быть частью чего-то, например, partial content.
должны быть идемпотентными... множественный вызов метода с одними и теми же параметрами будет всегда возвращать один и тот же результат
Во-первых, по хорошему должен, а не будет. Во-вторых, результат множественного вызова должен приводить к таким же "последствиям", что и единичный вызов. Про набор возвращаемых данных речи не идет. Было бы глупо ожидать, что возвращаемые данные всегда остаются такими же.
В общем, цель была благая, но "ультимативный" гайд больше похож на статью для галочки.
Видимо имелось в виду, что сам протокол не обязывает передавать идентификаторы сессий и не обязывает хранить некое состояние, привязанное к клиенту. Потому как чуть менее чем всегда приложения могут менять состояние и могут отличить одного клиента от другого.
Имелось в виду именно то, что написано. Протокол не умеет хранить состояние между запросами и это одна из главных его архитектурных особенностей. Передача данных через куки, это специальная механика, которая позволяет решить проблему передачи состояния через заголовки без необходимости менять архитектуру протокола. И об этом будет следующая статья.
Это зависит от соглашений, принятых в конкретной команде. Вообще создание ресурсов делают через POST, а изменение через PUT / PATCH.
Тут я правда ошибся, 201 для POST должен возвращаться. Спасибо, что подсветили.
Формат query string никак не специфицирован протоколом. Большинство серверов сейчас разбирают по аналогии с x-ww-form-urlencoded, но на заре веба можно было встретить строки запроса с другими разделителями (; например).
Все верно, формат не стандартизирован. Однако разделитель & является рекомендацией W3C и де-факто стандартом. Так что, как веб сервера делали это на заре своего существования не имеет никакого значения. Важно то, как это работает сейчас.
Тут вступает в игру Transfer-Encoding
Эти случаи будут рассмотрены в следующих статьях.
Во-вторых, результат множественного вызова должен приводить к таким же "последствиям", что и единичный вызов.
Тут правда не удачную формулировку выбрал. Спасибо, что подсветили. Поправил в статье.
Ультимативный гайд по HTTP. Структура запроса и ответа