4種主流的API架構風格對比

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"兩個單獨的應用程序需要中介程序才能相互通信。 因此，開發人員經常需要搭建橋樑——也就是應用程序編程接口（API），來允許一個系統訪問另一個系統的信息或功能。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"爲了快速、大規模地集成不同的應用程序，API使用協議或規範來定義那些通過網絡傳輸的消息的語義和信息。這些規範構成了API的體系結構。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在過去，人們已經發布了多種不同的API架構風格。每個架構風格都有它獨有的標準化數據交換的模式。這一系列的API架構風格的選項，引發了大量的關於哪種架構風格纔是最好的爭論。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.infoq.cn\/resource\/image\/5d\/fe\/5df831c837786042195858a0276e01fe.png","alt":null,"title":"","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"不同時間的API架構風格，圖源：Rob Crowley"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"今天，許多API的使用者將REST稱作“消亡的REST”（REST in peace），並且爲GraphQL感到歡欣鼓舞。而十年前，又完全是另一幅光景：REST是替代SOAP的贏家。這些觀點的問題在於，它們的出發點只是爲某種技術背書，而不是去考慮它實際的屬性和特性如何與當前的需求相匹配。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.infoq.cn\/resource\/image\/d6\/29\/d60faf458f95206f34ed88c074d09e29.png","alt":null,"title":"","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"四種API架構風格"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"RPC：調用另一個系統的函數"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"遠程過程調用是一種允許在不同上下文中遠程執行函數的規範。 RPC擴展了本地過程調用的概念，並將其放在HTTP API的上下文中。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"最初的XML-RPC是存在問題的，因爲很難確保XML有效負載的數據類型。因此，後來RPC API開始使用一個更具體的JSON-RPC規範，該規範被認爲是SOAP的更簡單的替代方案。gRPC是Google在2015年開發的最新RPC版本。gRPC可插拔支持負載均衡、追蹤、運行狀況檢查和身份驗證，它非常適合連接不同的微服務。"}]}]}