後REST時代正在來臨
現在，或多或少所有大型API都是RESTful。它會永遠保持這種狀態嗎？似乎不太可能。下一個是什麼？
REST是什麼？
它通俗地用於表示任何基於HTTP的API。實際上，它們中的絕大多數都對具有URI的資源進行CRUD操作，因此在原始意義上可以說是RESTful; 雖然這些天我偶然聽到“CRUDL”，其中L代表List。
在我工作的AWS，我們幾乎總是在區分“控制面板”和“資料面板”。例如，考慮我們的資料庫即服務ofollow,noindex" target="_blank">RDS ; 控制面板應用程式是您建立，配置，備份，啟動，停止和刪除資料庫的位置。資料面板是SQL，帶有連線池和所有RDBMS行李。
有趣的是，控制面板非常漂亮，但資料面板根本不存在。（這不一定是資料庫的事情：DynamoDB的資料面板非常RESTful。）
我覺得有一個模式：幾乎控制面板都是REST風格的，因為，這就是你將要建立和刪除的東西。資料面板可能是另一個故事; 我在這裡的第一個預測是，無論什麼是什麼，只要能取代REST都將首先在資料面板上開始，因為控制平面和REST非常適合。
RESTful缺陷
我們想要超越REST的原因是什麼？我列舉一些：
- 延時 ：設定和拆除你想要做的每一個小小的操作的HTTP連線不是免費的。幾十年的努力降低了成本，但仍然如此。很多使用MQ的原因之一是他們不想要 RESTful介面。
- 耦合：多數REST請求同步執行; 也就是說，你通過（GET，POST，PUT，等等）呼叫，然後你必須停下來，等待到得到你的結果。現在您的請求可能會返回202 Accepted，在這種情況下，您可能希望傳送一個URI以作為webhook回撥，或者在您可以輪詢的響應中獲取一個URI。但在所有這些情況下，耦合仍然非常厲害: 呼叫者必須保持某種關於請求的狀態，直到呼叫者完成它。
- 壽命短 : 處理一些請求需要幾毫秒。涉及大量的編排服務的，偶爾的人工互動則需要很長時間，讓執行緒等待的想法是荒謬的。
關於GraphQL
由於RESTful介面傾向於很好地告訴您單個資源，因此可能會導致浪費的請求。因此，GraphQL允許您在單個請求中從多個資源中挑選任意選擇的欄位。據推測，伺服器端實現會在資料中心內發出請求，這些呼叫更便宜，然後組裝您的GraphQL輸出，但無論如何這不再是您的問題。
關於RPC
這幾天，我想我必須指的是gRPC。我不知道，我已經老了，我看到一代又一代的RPC框架慘遭失敗; 脆弱，需要大量配置，並且無法實現預期的效能優勢。聞起來就像讓RESTful API更加緊密耦合，對我而言，很難看出這是一場勝利。但我可能是錯的。
後REST：訊息和事件
雲基礎設施會終結一切，你所要做的是通過訊息和事件和其打交道。
後REST：編排
其中“工作流程”是指跟蹤具有多個步驟的計算狀態的服務，其中任何一個步驟可能需要任意長時間，可能會失敗，可能需要重試，其行為和輸出會影響後續選擇輸出步驟及其行為。
越來越多（例如）Lambda函式不是提供請求和返回響應，而是在提供輸入的工作流的上下文中執行，等待它們完成，並將其輸出路由到更下游。
後REST：持久連線
第一個是已經廣泛部署的HTTP / 2，它允許您跨單個網路連線複用多個HTTP請求。智慧地使用，它可以為您帶來永久連線的一些好處。但它仍然與TCP密切相關，這有一些不幸的副作用，我不會在這裡深入探討，部分原因是因為這不是我深刻理解的事情。但我希望看到許多應用程式和服務從HTTP / 2中獲得很好的價值; 在某些程度上，因為就客戶端而言，他們仍在製作和響應之前的舊HTTP請求。
下一個步驟是QUIC，放棄TCP而支援UDP，同時保留HTTP語義。這已經在很多Google產品上投入使用。我個人認為這是一個非常重要的事情; HTTP如此成功的原因之一是它的連線是短暫的，因此在工作時遭受破壞的可能性要小得多。在HTTP世界中，您一次需要處理的最多是一個失敗的請求，而連線斷開只是可能發生的原因之一。UDP使得連線斷開的問題消失。
當然，沒有免費的午餐。如果您使用UDP，你不會得到TCP的TC。