带有 HTTP/2 的 REST API答案

【问题标题】：REST API with HTTP/2带有 HTTP/2 的 REST API
【发布时间】：2015-10-19 23:40:35
【问题描述】：

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

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

【问题讨论】：

【解决方案1】：

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

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

因此，基于 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，并设置所需的基础架构来支持这一点（从受信任的机构购买证书、更新证书等）。

【讨论】：

所以您不必更改有关 Web 应用程序/api 的任何内容？只需在服务器上配置一下（包括TLS）就可以了？
正确。我不能代表所有的 Web 服务器，但对于 Jetty（我是提交者），您只需使用 http2 模块配置 Jetty 就可以了。
一位名叫 Guy Levin 的作者在 DZone 文章中有一个逐字记录的副本：dzone.com/articles/benefits-of-rest-apis-with-http2#20（或者反过来，只是在这里查看日期......）
这是一个很好的总结，但还有一个补充：服务器推送对于 REST API 非常有用，它改变了一切，也解决了读取不足/过度获取问题。 apisyouwonthate.com/blog/… Vulcain 利用更新的 Preload 标头让客户端选择他们想要的推送。 github.com/dunglas/vulcain#pushing-relations
@Phil 服务器推送可以做什么，而 Web 套接字已经多年无法做到？对于 REST API，我还没有看到 HTTP/2 比 1.1 有任何真正的优势。

【解决方案2】：

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

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

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

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

但是，Push 尚未在服务器和客户端基础架构中广泛实施。

【讨论】：

我猜 HTTP/2 确实引入了一些新的语义（例如服务器推送），但它并没有改变任何现有的 HTTP/1.x 语义，因此它是向后兼容的。因此，Web 应用程序可以透明地升级到 HTTP/2。

【解决方案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 推送来抢先填充浏览器缓存。

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

【讨论】：