> For the complete documentation index, see [llms.txt](https://sallyit.gitbook.io/akademiait/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sallyit.gitbook.io/akademiait/hard-skills/integracii/vidy-integracii/sinkhronnoe-vzaimodeistvie/rest/restful-principy/otsutstvie-sostoyaniya-avtorizaciya/keshirovanie.md).

# Кеширование

**Кэширование** — это возможность хранить копии часто используемых данных в нескольких местах по пути запроса-ответа.

Кэширование хранит и извлекает данные из программного или аппаратного компонента. Когда клиент (например, браузер) отправляет запрос REST API, он может сохранить ответ API в кеше. В следующий раз, когда клиент инициирует этот запрос, он получит более быстрый ответ, поскольку серверу не придется обрабатывать его заново. Кэширование жизненно важно для каждого API. Это экономит накладные расходы и сокращает время отклика.

### Зачем использовать кэширование? <a href="#zachem-ispolzovat-keshirovanie" id="zachem-ispolzovat-keshirovanie"></a>

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

#### Кеширование в REST <a href="#keshirovanie-v-rest" id="keshirovanie-v-rest"></a>

Кэшируемость — одно из архитектурных ограничений REST.

* **GET-** запросы должны кэшироваться по умолчанию — до тех пор, пока не возникнет особое условие. Обычно браузеры рассматривают все запросы GET как кэшируемые.
* **POST-** запросы не кэшируются по умолчанию, но их можно сделать кэшируемыми, если к ответу добавлен `Expires` заголовок или `Cache-Control` заголовок с директивой, явно разрешающей кэширование.
* Ответы **PUT** и **DELETE** запросы вообще не кэшируются.

### Как управлять кешем <a href="#kak-upravlyat-keshem" id="kak-upravlyat-keshem"></a>

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

#### Expires <a href="#expires" id="expires"></a>

HTTP- заголовок `Expires` указывает до какого времени можно хранить ресурс в кэш. По истечении этого времени кэшированное представление считается устаревшим и должно быть повторно проверено на исходном сервере.

#### Last-Modified <a href="#last-modified" id="last-modified"></a>

Заголовок `Last-Modified` указывает, когда связанный ресурс был последний раз изменен. Этот заголовок используется в качестве средства проверки, чтобы определить, совпадает ли полученный ответ сервера с ранее сохраненным ресурсом в кэше клиента.

#### ETag <a href="#etag" id="etag"></a>

Заголовок `ETag` — это токе&#x43D;*,* который генерируется сервером на основе содержимого ресурса и позволяет однозначно идентифицировать его состояние. Если ресурс по данному URL-адресу изменяется, сервер создет новый токен `Etag`. Сравенение старого и нового токена от сервера поможет определить, являются ли два ресурса одинаковыми и нужно ли обновлять кэш на клиенте.

#### Cache-Control <a href="#cache-control" id="cache-control"></a>

Значение заголовка `Cache-Control` содержит одну или несколько директив, разделенных запятыми . Эти директивы определяют, кэшируется ли ответ, и если да, то кем и как долго, например, `max-age` или `s-maxage` директивы.

Например, если вы установите значение `Cache-Control` в заголовке ответа API на `max-age=60`, браузер будет хранить кэш в течение шестидесяти секунд.

### Инвалидация кеша <a href="#invalidaciya-kesha" id="invalidaciya-kesha"></a>

**Инвалидация кэша** — это процесс, при котором компьютерная система объявляет записи кэша недействительными и удаляет или заменяет их. Если данные изменяются, они должны быть инвалидированы в кэше, в противном случае это может привести к несогласованному поведению приложения.

#### Инвалидация по TTL <a href="#invalidaciya-po-ttl" id="invalidaciya-po-ttl"></a>

При сохранении данных в кэш для них устанавливается время жизни (TTL - time to live) и данные будут автоматически удалены через это время.

Основная проблема заключается в подборе TTL. Если TTL слишком короткий, то запись может “протухнуть” и стать недействительной раньше, чем обновление было бы необходимо, что приведет к отправке повторного запроса в источник данных. Если TTL слишком длинный, то запись может содержать устаревшие данные, что может привести к ошибкам или неправильной работе приложения. Обычно ответ на этот вопрос подбирается эмпирическим путем.

#### Инвалидация по событию <a href="#invalidaciya-po-sobytiyu" id="invalidaciya-po-sobytiyu"></a>

При таком подходе данные инвалидируют при наступлении некого события – обычно это обновление данных в источнике. В качестве события для инвалидации данных может выступать время последней модификации данных. Такой способ используется в HTTP.

Источники: