後REST時代正在來臨

banq發表於2018-11-20

現在,或多或少所有大型API都是RESTful。它會永遠保持這種狀態嗎?似乎不太可能。下一個是什麼?

REST是什麼?
它通俗地用於表示任何基於HTTP的API。實際上,它們中的絕大多數都對具有URI的資源進行CRUD操作,因此在原始意義上可以說是RESTful; 雖然這些天我偶然聽到“CRUDL”,其中L代表List。
在我工作的AWS,我們幾乎總是在區分“控制皮膚”和“資料皮膚”。例如,考慮我們的資料庫即服務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。
​​​​​​​
 

相關文章