Если браузер может кэшировать запросы PATCH
Если вы выбираете изображение для отображения второй или n+1 раз, или аналогичным образом получаете JSON, и ничего не изменилось, тогда браузер на самом деле не должен загружать / извлекать контент. Вот как GET-запросы работают с кэшированием.
Но мне интересно, гипотетически, если вместо использования GET вы используете PATCH для получения изображения или JSON. Интересно, может ли браузер по-прежнему использовать свою кэшированную версию, если ничего не изменилось, или что нужно сделать, чтобы PATCH работал как GET, чтобы он не извлекал кэшированное содержимое.
1 ответ
Важно понимать, что PATCH не для получения чего-либо. Вы вносите изменения на сервере, и в ответе может содержаться информация о том, как это изменение было применено.
HTTP-запросы, кроме GET иногда может быть кешируется. Чтобы узнать, если PATCH Вы можете прочитать RFC. RFC имеет это, чтобы сказать:
Ответ на этот метод кэшируется только в том случае, если он содержит явную информацию о свежести (например, заголовок Expires или директиву Cache-Control: max-age), а также заголовок Content-Location, соответствующий Request-URI, указывающий, что PATCH Тело ответа является представлением ресурса. Кэшированный ответ PATCH может использоваться только для ответа на последующие запросы GET и HEAD; он НЕ ДОЛЖЕН использоваться для ответа на другие методы (в частности, PATCH).
Это уже говорит "нет", делая PATCH запрос дважды не приведет к пропуску второго.
Второе, на что нужно обращать внимание при использовании HTTP-методов, это то, являются ли они идемпотентными или безопасными. PATCH это ни то, ни другое
RFC7231 может сказать о кешируемых методах:
Как правило, безопасные методы, которые не зависят от текущего или авторитетного ответа, определяются как кешируемые; эта спецификация определяет GET, HEAD и POST как кешируемые, хотя подавляющее большинство реализаций кеша поддерживают только GET и HEAD.
Оба из них предполагают, что "нет", PATCH не кэшируется, и нет набора заголовков HTTP, который сделает это так.