http - 带有 HTTP/2 的 REST API

Question

几个月前，HTTP/2 发布为RFC7540。
这将如何影响基于 HTTP/1.1 构建的现有 REST API？

根据Wikipedia，HTTP/2 添加了新功能。
我们如何利用这些新功能？

Answer 1

HTTP 的主要语义在 HTTP/2 中得到了保留。这意味着它仍然具有HTTP methods诸如GET、POST等HTTP headers、 和URIs来标识资源。

HTTP/2 相对于 HTTP/1.1 的变化是通过网络传输 HTTP 语义（例如“我想在主机上获取PUT资源”）的方式。/foodomain.com

鉴于此，基于 HTTP/1.1 构建的 REST API 将继续像以前一样透明地工作，无需对应用程序进行任何更改。运行应用程序的 Web 容器将代表应用程序负责将新的有线格式转换为通常的 HTTP 语义，并且应用程序只会看到更高级别的 HTTP 语义，无论它是通过 HTTP/1.1 还是 HTTP/ 2 过线。

因为 HTTP/2 有线格式更有效（特别是由于多路复用和压缩），HTTP/2 之上的 REST API 也将受益于此。

HTTP/2 中的另一个主要改进是HTTP/2 Push针对相关资源的高效下载，它在 REST 用例中可能没有用。

HTTP/2 的一个典型要求是通过 TLS 部署。这需要部署人员从 迁移http到https，并设置所需的基础设施来支持它（从受信任的机构购买证书，更新它们等）。

Answer 2

HTTP/2 规范故意没有为应用程序程序员引入新的语义。事实上，主要的客户端库（iOS 上的 NSUrlSession、Android 上的 OkHttp、React Native、浏览器环境中的 JS）对开发人员透明地支持 HTTP/2。

由于 HTTP/2 能够通过单个 TCP 连接多路复用多个请求，过去应用程序开发人员实施的一些优化，例如请求批处理将变得过时甚至适得其反。

推送功能可能会用于传递事件，并且能够在某些应用程序中替代轮询和可能的 websocket。

将 HTTP/2 中的服务器推送功能应用于 REST API 的一种可能应用是能够通过提前将预期请求推送到客户端而不是等待它们到达来加速传统应用程序，即反向代理级别。即在登录请求完成后立即将答案推送到用户配置文件和其他常见的 API 调用。

然而，Push 尚未在服务器和客户端基础设施中广泛实施。

Answer 3

我看到的主要好处是用于超媒体 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
    ]
}

如果服务器知道客户端将来可能想要执行某些 GET 请求，HTTP/2 Push 可用于抢先填充浏览器缓存。

在上面的例子中，如果 HTTP/2 服务器推送被激活并正确配置，它可以传递/post/3,/post/13和. 连续发布这些帖子之一将导致缓存响应。此外，缓存摘要草案将允许客户端发送有关其缓存状态的信息，避免不必要的推送。对于超媒体驱动的 API，这比HAL等嵌入式主体更实用。/post/06/user/3GETs

有关原因的更多信息：当今嵌入 REST 的问题以及如何使用 HTTP/2 解决它。