REST API с HTTP/2

Основная семантика HTTP была сохранена в HTTP/2. Это означает, что у него все еще есть HTTP methods, такие как GET, POST и т. д., HTTP headers и URIs для идентификации ресурсов.

Что изменилось в HTTP/2 по сравнению с HTTP/1.1, так это то, как семантика HTTP (например, «Я хочу PUT ресурс /foo на хосте domain.com») передается по сети.

В этом свете REST API, построенные на HTTP/1.1, будут продолжать работать прозрачно, как и раньше, без каких-либо изменений в приложениях. Веб-контейнер, который запускает приложения, позаботится о переводе нового формата проводника в обычную семантику HTTP от имени приложений, а приложение просто увидит семантику HTTP более высокого уровня, независимо от того, был ли он передан через HTTP/1.1 или HTTP/. 2 по проводу.

Поскольку проводной формат HTTP/2 более эффективен (в частности, благодаря мультиплексированию и сжатию), API REST поверх HTTP/2 также выиграют от этого.

Другое важное улучшение, представленное в HTTP/2, HTTP/2 Push, направлено на эффективную загрузку связанных ресурсов и, вероятно, бесполезно в сценарии использования REST.

Типичным требованием HTTP/2 является развертывание через TLS. Для этого от развертывателей требуется перейти с http на https и настроить необходимую инфраструктуру для поддержки этого (купить сертификаты у доверенного центра, обновить их и т. д.).

Спецификация HTTP/2 намеренно не вводила новую семантику для разработчиков приложений. Фактически, основные клиентские библиотеки (NSUrlSession на iOS, OkHttp на Android, React Native, JS в среде браузера) поддерживают HTTP/2 прозрачно для вас как разработчика.

Из-за возможности HTTP/2 мультиплексировать множество запросов по одному TCP-соединению некоторые разработчики приложений для оптимизации, реализованные в прошлом, такие как пакетная обработка запросов станет устаревшей и даже контрпродуктивной.

Функция push, вероятно, будет использоваться для доставки событий и сможет заменить опрос и, возможно, веб-сокеты в некоторых приложениях.

Одно из возможных применений функции push-уведомлений сервера в API-интерфейсах HTTP/2 для REST — это возможность ускорить устаревшие приложения, т. е. на уровне обратного прокси-сервера, заблаговременно отправляя ожидаемые запросы клиенту, а не ожидая их прибытия. т.е. отправлять ответы в профиль пользователя и другие распространенные вызовы API сразу после завершения запроса на вход.

Однако технология Push еще не получила широкого распространения в серверной и клиентской инфраструктуре.

Основное преимущество, которое я вижу, — это Server Push для гипермедиа RESTful API, которые содержат ссылки на ресурсы, часто абсолютные URL-адреса, зависящие от домена, такие как /post/12.

Пример: GET https://api.foo.bar/user/3

{
  "_self": "/user/3"
  "firstName": "John",
  "lastName": "Doe",
  "recentPosts": [
    "/post/3",
    "/post/13",
    "/post/06
    ]
}

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

В приведенном выше примере, если HTTP/2 Server Push активирован и правильно настроен, он может доставить /post/3, /post/13 и /post/06 вместе с /user/3. Последовательное GETs для одного из этих сообщений приведет к кешированию ответов. Кроме того, черновик кэш-дайджеста позволит клиенту отправлять информацию о состоянии своего кеша, избегая ненужных пушей. Это гораздо более практично для API, управляемых Hypermedia, чем для встроенных тел, таких как HAL.

Подробнее о причинах здесь: Проблемы с встраиванием в REST сегодня и как их можно решить с помощью HTTP/2.