1. Кешування
Кешування — це можливість зберігати копії даних, до яких часто звертаються, у кількох місцях на шляху запит-відповідь.
Коли споживач запитує представлення ресурсу, запит проходить через кеш або серію кешів (локальний кеш, кеш-проксі-кеш або зворотний проксі-сервер) до служби, на якій розміщено ресурс.
Якщо будь-який із кешів уздовж шляху запиту має свіжу копію запитаного представлення, він використовує цю копію для задоволення запиту. Якщо жоден із кешів не може задовольнити запит, запит переходить до служби (або вихідного сервера, як його офіційно називають).
Використовуючи заголовки HTTP, вихідний сервер вказує, чи можна кешувати відповідь і, якщо так, ким і протягом якого часу.
Кеші вздовж шляху відповіді можуть приймати копію відповіді, але лише якщо метадані кешу дозволяють це робити.
Оптимізація мережі за допомогою кешування покращує загальну якість обслуговування такими способами:
- Зменшити пропускну здатність
- Зменшити затримку
- Зменшити навантаження на сервери
- Приховати збої мережі
2. Кешування в REST API
Можливість кешування є одним із архітектурних обмежень REST.
- Запити GET мають кешуватися за замовчуванням – доки не виникне спеціальна умова. Зазвичай браузери сприймають усі запити GET як такі, що кешуються.
- Запити POST не кешуються за замовчуванням, але їх можна зробити кешованими, якщо до відповіді додаєються заголовоки Expires або Cache-Control із директивою, яка явно дозволяє кешування.
- Відповіді
PUTтаDELETEзапити взагалі не кешуються.
Зауважте, що дати HTTP завжди виражаються в GMT , а не в місцевому часі.
3. Заголовки керування кеш-пам’яттю
Нижче наведено основні заголовки відповіді HTTP, які ми можемо використовувати для керування поведінкою кешування :
3.1. Expires
HTTP – заголовок Expires визначає абсолютний час закінчення терміну дії для кешованого представлення. Після закінчення цього часу кешоване представлення вважається застарілим і має бути повторно перевірено на вихідному сервері.
Щоб вказати, що подання ніколи не закінчується, послуга може включати час до одного року в майбутньому.
Expires: Fri, 20 May 2016 19:20:49 GMT
3.2. Cache-Control
Значення заголовка містить одну або більше директив, розділених комами. Ці директиви визначають, чи кешується відповідь, і якщо так, то ким і протягом якого часу, наприклад директиви:max-age або s-maxage.
Cache-Control: max-age=3600
Відповіді, які можна кешувати (на запити GET або POST), також повинні включати валідатор — або ETag, або заголовок Last-Modified .
3.3. ETag
Значення ETag — це непрозорий маркер рядка, який сервер пов’язує з ресурсом, щоб унікально ідентифікувати стан ресурсу протягом його життя.
Якщо ресурс за заданою URL-адресою змінюється, необхідно створити нове Etag значення. Їх порівняння може визначити, чи є два представлення ресурсу однаковими.
Під час запиту ресурсу клієнт надсилає на сервер ETag у полі заголовка If-None-Match . Сервер збігається з Etag запитуваного ресурсу та значенням, надісланим у заголовку If-None-Match. Якщо обидва значення збігаються, сервер надсилає назад статус 304 Not Modified без тіла, який повідомляє клієнту, що кешована версія відповіді все ще підходить для використання (валідна).
ETag: "abcd1234567n34jv"
3.4. Last-Modified
У той час як заголовок Date відповіді вказує, коли відповідь була згенерована, заголовок Last-Modified вказує, коли пов’язаний ресурс востаннє змінювався.
Цей заголовок використовується як засіб перевірки, щоб визначити, чи ресурс збігається з тим, який раніше зберігався в кеші клієнта. Менш точний, ніж заголовок ETag але добре користати це як резервний механізм.
Значення Last-Modified не може перевищувати значення Date. Зауважте, що заголовок Date указано в списку заборонених імен заголовків.
Last-Modified: Fri, 10 May 2016 09:17:49 GMT