API REST с HTTP/2

Несколько месяцев назад HTTP/2 был опубликован как RFC7540. Как это повлияет на существующий REST API, основанный на HTTP/1.1

В соответствии с wikipedia, HTTP/2 добавил новые функции. Как мы можем воспользоваться преимуществами этих новых функций?

Не стесняйтесь улучшать этот вопрос.

Спасибо.

Ответы

Ответ 1

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

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

В этом свете API-интерфейсы REST, построенные на 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 и настраивали необходимую инфраструктуру для поддержки этого (покупайте сертификаты из доверенного органа, обновляйте их и т.д.).

Ответ 2

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

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

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

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

Однако Push еще не широко внедрен в инфраструктуру серверов и клиентов.