REST API 与 HTTP/2

Question

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

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

Answer 1

HTTP/2 保留了 HTTP 的主要语义。也就是说它还有HTTP methods如GET、POST等，HTTP headers，还有URIs来标识资源

HTTP/2 相对于 HTTP/1.1 的变化是 HTTP 语义（例如 "I want to PUT resource /foo on host domain.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 规范有意没有为应用程序员引入新的语义。事实上，主要的 client-side 库（[=28= 上的 NSUrlSession、[=27= 上的 OkHttp]、浏览器环境中的 React Native、JS）支持 HTTP/2 对开发人员来说是透明的。

由于 HTTP/2 能够在单个 TCP 连接上多路复用许多请求，应用程序开发人员过去实施的一些优化，例如 request batching 将变得过时，甚至 counter-productive。

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

HTTP/2 到 REST API 中服务器推送功能的一个可能应用是能够加速遗留应用程序，即通过提前将预期请求推送到客户端而不是反向代理级别等待他们的到来。 IE。在登录请求完成后立即推送对用户个人资料和其他常见 API 调用的回答。

然而，推送尚未在服务器和客户端基础架构中广泛实施。

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
    ]
}

HTTP/2 Push can be used to preemptively populate the browser cache if the server knows the client will likely want to do certain GET requests in the future.

在上面的例子中，如果 HTTP/2 服务器推送被激活并正确配置，它可以传送 /post/3、/post/13 和 /post/06 以及 /user/3. 对其中一个帖子的连续 GETs 将导致缓存响应。另外，the cache digest draft would allow client to send information about the state of their cache, avoiding unnecessary pushes. This is much more practical for Hypermedia-driven APIs then embedded bodies such has does HAL.

有关原因的更多信息：The problems with embedding in REST today and how it might be solved with HTTP/2。

REST API 与 HTTP/2

REST API with HTTP/2

rest

http

http2