Блог

Я читал документы HTTP-запроса и увидел это:

Каждый [HTTP-запрос] реализует различную семантику, но некоторые общие функции являются общими для группы из них: например, метод запроса может быть безопасным, идемпотентным или кэшируемым.

Должен ли я реализовывать эти функции? В частности, что, если я отслеживаю, когда мои клиенты в последний раз запрашивали некоторую информацию, которая заставила бы мой запрос GET изменить состояние сервера? Или, если я использовал запрос PUT для добавления данных, а не для замены, делая его не идемпотентным? В документах конкретно указано, что не следует делать вышеуказанные 2 вещи:

Запросы, использующие GET, должны извлекать только данные.

Методы также могут обладать свойством «идемпотентности» в том смысле, что (помимо ошибок или проблем с истечением срока действия) побочные эффекты N> 0 идентичных запросов такие же, как и для одного запроса. Методы GET, HEAD, PUT и DELETE совместно используют это свойство

В целом, да.

Например, вы должны использовать POST или PATCH для добавления.

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

В основном клиенты будут делать предположения на основе метода. И это не только клиенты, но и любые прокси-серверы между вами и вашими клиентами, например, CDN, прокси-серверы браузера и т. Д..

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

Многие клиенты, включая браузеры, предполагают, что GET это может быть возвращено из их локального кэша, поэтому они даже не будут разговаривать с вашим сервером. Для этого есть заголовки ответов управления кэшем.

Если вам нужно поддерживать состояние клиента, возможно, что HTTP не является подходящим протоколом для вас, HTTP стремится быть масштабируемым, а поддержание состояния клиента является препятствием для масштабируемости.