應用程式設計介面，或稱API，是計算機程式或服務之間相互通訊的一種方式。這種通訊通常發生在一個API端點上，由客戶端消費的程式暴露出來。
本文將比較兩種流行的構建API的方法：表徵性狀態轉移（REST）API和Web API。
什麼是REST API？
與流行的看法相反，REST API不是一個協議。它是一種架構，而且是開發API的最流行的架構。正如在《GraphQL與REST： 你需要知道的一切》一文提及，REST是無狀態的，所以在請求之間沒有資料或狀態被儲存。
REST還為構建通過HTTP通訊的應用程式定義了多種架構約束：
- 客戶端-伺服器架構
- 無狀態
- 統一的介面
- 快取性
- 分層系統架構
- 按需編寫程式碼
REST比其他API協議或架構更容易使用。它還提供了許多其他的好處，使它成為許多開發者構建API的首選：
- 多樣的訊息格式：REST API大多與JSON一起用於序列化資料，但可以與多種訊息格式一起工作，包括JSON、HTTP、純文字和XML。這一系列的選擇使它比服務物件訪問協議（SOAP）等主要通過HTTP與XML一起工作的協議更有優勢，與XML相比，JSON等選項明顯更輕，對陣列的支援更靈活，而且更容易解析。
- HTTP方法：REST通常使用
GET、POST、PATCH、DELETE或PUT中的任何一種方法進行資料檢索，並根據服務的實現提出請求。這些方法返回常見的HTTP成功和失敗程式碼。其他方法包括OPTIONS、HEAD和TRACE。這些方法在服務之間是不一致的，因為一些提供者可能只根據他們的需要實現一個方法。 - 解耦架構：REST有一個客戶-伺服器架構，所以它的邏輯與表現形式是分離的–多個部分可以同時工作而不受干擾。
- 可擴充套件性： REST的API很簡單，這使得它們可以直接使用。然而，如果你需要擴大規模，你可以建立新的端點來納入更復雜的邏輯。
- 快取性：雖然REST是無狀態的，但客戶端的伺服器響應可以被快取，以避免重複多餘的請求。伺服器響應通常會給出關於如何執行快取的資訊–客戶端會在給定的時間內快取請求。
- 安全性：在大多數情況下，REST端點是通過HTTPS端點暴露的，這確保了所有的API通訊都是使用TLS/SSL的安全。REST還支援其他授權和認證方案，如OAuth2和JSON Web Tokens（JWT）。
什麼是Web API？
Web API只是一個通過HTTP訪問伺服器資源的介面。這個術語指的是概念，而不是任何特定的技術–Web API可以用各種技術建立，如Java和ASP.NET。Web API使用一個開源的介面，並利用許多客戶端實體，如瀏覽器、智慧手機、平板電腦和膝上型電腦。
網路應用程式介面實現了協議規範的概念，如快取、版本管理和不同的內容格式。一個Web API可能是也可能不是REST API，這取決於它的構建方式。Web API通常用於分散式系統，在不同的裝置上提供服務，如智慧手機和膝上型電腦，並且僅限於網路應用的客戶端。
下面是兩個廣泛使用的Web API的例子：
- 谷歌APIs： 其中包括YouTube APIs，它允許開發者將YouTube視訊嵌入他們的應用程式，如網站，以及谷歌地圖API，它允許開發者使用JavaScript或Flash介面在網頁上使用或嵌入谷歌地圖。
- 推特API： 這些包括Twitter搜尋API，它提供與Twitter搜尋互動的方法，以及REST API，它允許你訪問Twitter的核心資料。
Web API是作為系統對系統的互動進行的。以下是這樣一個API內的資料可能的流動情況：
- 客戶端裝置向網路伺服器傳送請求。
- 網路伺服器接收請求，對其進行處理，然後將其發回給客戶端裝置執行。
- 輸出結果被呈現給使用者。
網路應用程式介面的有利特徵包括：
- 輕量級架構： Web API在頻寬有限的裝置中表現出色，如智慧手機。
- 描述性的訊息頭： Web API有描述性的訊息頭，可能包含內容型別、安全方案或如何處理快取的資訊。
- 支援所有的資料型別： Web API的主體可以用於任何東西，包括二進位制檔案（視訊、影象、文件）、普通XML、JSON和HTML。
- 面向資源的服務： 一個Web API可以以符合REST架構的方式暴露資源。
- 易於配置和設定： Web API很容易設定和執行。
Web API與REST API
現在，讓我們更詳細地比較這兩種API。
架構的相似性
Web和REST API在架構上有一些相似之處，讓我們來看看。
- 無狀態性： HTTP請求是孤立發生的，從根本上說是無狀態的，因為每個請求都包含足夠的資訊來完成它。多個請求只有通過共享資訊，如cookies或會話ID，才能相互關聯。由於沒有狀態同步，減少了複雜性並提高了效能，因為伺服器不需要跟蹤客戶端的請求。併發請求也可以在多個伺服器上進行擴充套件。
- 分層架構： 它們都支援分層架構設計，API部署、請求認證和儲存可以在多個伺服器上發生。
- 面向資源： 在面向資源的架構中，資源被對映到統一資源識別碼（URI）。Web和REST API都是面向資源的，因為它們通過URI暴露資源。
- 快取性： 在REST和Web API中，每次呼叫時返回相同資訊的查詢都是快取的。例如，一個端點上的OPTION呼叫將被快取，因為無論呼叫多少次，其輸出都是一樣的。這個屬性被稱為idempotence，是確定資料何時可以被快取的良好基礎。Idempotence在REST中一直被考慮，儘管在Web API中並沒有那麼多。一個無效的API呼叫是指無論呼叫多少次，其結果都不會改變，即使伺服器上有可能發生變化。idempotent方法的例子包括GET、HEAD和OPTIONS。
架構差異
雖然Web APIs和REST APIs有類似的架構模式，但它們也有一些關鍵的區別。
- 客戶端和伺服器端的協調： REST APIs有鬆散的耦合架構，允許在客戶端和伺服器端獨立開發。有了Web APIs，客戶端和伺服器之間的變化被更精細地協調。
- 介面： 根據實施細節，REST APIs傾向於使用行業標準的介面。Web API使用自定義介面，這取決於API供應商。
通訊
Web API足夠靈活，可以利用任何通訊方式，而REST API主要用於JSON、XML和純文字。這些選擇意味著REST API在文字資料傳輸方面表現良好，例如針對資料庫的建立、讀取、更新和刪除（CRUD）操作，但在涉及二進位制資料時，限制性更強。
對於需要二進位制資料的服務，如音樂或視訊流服務，Web APIs提供了更好的體驗，因為它們支援更多的訊息格式。
使用案例
雖然這些API格式在很多情況下是可以互換的，但有幾個場景是一個比一個好的：
- 雲服務和應用程式： 由於其無狀態的性質，REST API被用於雲服務中，因為無狀態的元件可以擴充套件和重新部署以適應變化。雲服務和指標通常最好以REST API的形式暴露，因為幾乎不需要定製程式碼。
- 流媒體服務： Web API對記憶體或頻寬受限的裝置上的應用二進位制資料有更好的支援和低開銷，所以它們最適合需要流媒體的服務。
- 資料庫操作（CRUD）： 通過REST API暴露CRUD功能比Web API更簡單和容易。
REST API對於需要訪問不按簡單層次排列的資源的複雜請求難以管理。這是因為它的URI引用了資源，這意味著管理這種情況需要操作URI路徑、查詢引數和請求主體，這違背了REST的目的。在這種情況下，Web API是首選，因為它允許定製，並對URI響應和請求頭有廣泛的支援。
由於支援非同步呼叫等技術–使用REST架構不容易實現–Web API是滿足複雜API需求的途徑。
小結
Web和REST API是用來構建提供資源並通過HTTP進行通訊的應用程式。REST描述了統一介面上的架構約束，而Web API一般是一個概念，可以是RESTful的，這取決於實現。
Web和REST API都是輕量級的格式，在很多情況下都可以互換。然而，與REST APIs相比，Web APIs提供了更多的定製體驗，支援更多的訊息型別，它支援伺服器和客戶端之間處理二進位制資料的複雜互動。
評論留言