帶有 HTTP/2 的 REST API

Question

幾個月前，HTTP/2 發布為RFC7540 。
這將如何影響基於 HTTP/1.1 構建的現有 REST API？

根據Wikipedia ，HTTP/2 添加了新功能。
我們如何利用這些新功能？

Answer 1

HTTP 的主要語義在 HTTP/2 中得到了保留。 這意味着它仍然具有GET 、 POST等HTTP methods 、 HTTP headers和URIs來識別資源。

HTTP/2 相對於 HTTP/1.1 的變化是通過網絡傳輸 HTTP 語義（例如“我想將資源/foo PUT主機example.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和/post/06以及/user/3 。 對這些帖子之一的連續GETs將導致緩存響應。 此外， 緩存摘要草案將允許客戶端發送有關其緩存狀態的信息，避免不必要的推送。 對於超媒體驅動的 API，這比HAL等嵌入式主體更實用。

有關原因的更多信息：當今嵌入 REST 的問題以及如何使用 HTTP/2 解決它。