Web API的簡史介紹

banq發表於2019-01-02
WebAPI

在20世紀90年代末和2000年代早期，分散式API在HTTP協議上的主要用途是以相對簡單的遠端過程呼叫（RPC）方式交換可擴充套件標記語言（XML）格式的文件。
諸如XML-RPC之類的協議演變為簡單物件訪問協議（SOAP），從而產生了廣為人知的Web服務方法。這些主要是機器到機器之間的互動，儘管它們使用全球資訊網技術，但它們在Web伺服器和Web客戶端（瀏覽器）之間很少使用。
HTTP上的SOAP呼叫涉及對HTTP端點的請求GET或POST請求，指定SOAPAction為HTTP標頭或URL查詢引數。雖然SOAP也可以支援不太常見的傳輸，例如電子郵件。XML名稱空間用於消除SOAP信封元素與Web服務定義的訊息體元素的歧義，但這可能無助於使人們更容易閱讀SOAP訊息。
SOAP請求的示例：

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <m:GetEndorsingBoarder xmlns:m="http://namespaces.snowboard-info.com">
      <manufacturer>K2</manufacturer>
      <model>Fatbob</model>
    </m:GetEndorsingBoarder>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

來自同一來源的SOAP響應示例：

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <m:GetEndorsingBoarderResponse xmlns:m="http://namespaces.snowboard-info.com">
      <endorsingBoarder>Chris Englesmann</endorsingBoarder>
    </m:GetEndorsingBoarderResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>


因為HTTP上的SOAP被限制到GET與POSTHTTP方法，它未能得到更廣泛的可用的HTTP方法的益處（如PUT，DELETE，HEAD和OPTIONS）和全範圍的與其相關聯的HTTP狀態程式碼。這會對可快取性和效能產生負面影響。

AJAX
2005年2月，Jesse James Garrett發表了一篇名為Ajax：Web應用程式的新方法的文章，其中詳述了Google開發的一種相對輕量級的方法，其中Web客戶端可以非同步地（即在後臺）從伺服器載入內容。代表非同步JavaScript和XML的AJAX很快成為使網站變得動態的流行方法，從而產生了“Web 2.0”概念。
雖然最初涉及載入HTML和XHTML文件片段，但開發人員很快就開始使用AJAX與Web伺服器交換資料，並且幾個因素（例如效能和跨瀏覽器相容性）導致逐漸從XML轉換為JavaScript Object Notation（JSON） ）作為資料格式的選擇。
一個將來自多個“Web 2.0”源的內容或資料組合在一起的網站稱為“混搭Mash-up”。雖然這個術語已大部分不再使用，但仍然可以在組織名稱中看到該術語的殘餘，例如Mashable（現在是Tibco的一部分）和Mashape。
AJAX的簡單性和jQuery等JavaScript庫的日益普及導致伺服器和瀏覽器之間使用Web API的爆炸式增長。隨著自2007年以來移動應用程式的興起，Web API的使用量進一步增長，這種方法現在與JavaScript，XML和瀏覽器本身脫鉤，有效地取代了其他Web API技術，如SOAP。

REST和RESTful API
REST--代表狀態轉移 -，這個詞是由Roy T. Fielding在2000年發表的博士論文中提出的; 建築風格與基於網路的軟體體系結構設計。它旨在描述像全球資訊網這樣的網路和諸如Web應用程式之類的軟體應該如何工作。它拒絕採用RPC風格的API方法，並提倡使用我們熟悉的全球資訊網功能，例如：

  • 有意義的資源識別符號，例如URI
  • 傳遞資源表示，而不是訊息或函式呼叫
  • 使用標準媒體型別和HTTP狀態程式碼
  • 在適當的地方明確支援快取

REST被描述為一種架構風格，這就是它應該如何看待它的原則和建議。從REST中可以學到很多東西，當面對複雜的設計決策時，它往往是一個很好的迴歸。REST不是“新的SOAP”，它們解決了完全不同的API風格，並以一種根本不同的方式實現。當應用於HTTP時，REST樣式也充分利用了這個底層協議，因此在實現良好時可以非常高效，儘管這不是它最初的重點。HTTP / 2改進帶來的好處只會進一步提高效能。但是，REST不是您必須遵守的標準，也不應被視為一條真正的道路，被視為福音。知道何時打破“規則”。
REST確實具有特定的約束，它適用於Web的設計以定義其架構風格，就像Palladian或新古典主義等架構風格用於劃分和描述建築結構的範圍一樣。如果API沒有表現出所有強制REST約束，則無法將其真正稱為RESTful API。這導致了像REST這樣的術語，甚至是RESTish這樣的術語，用於描述顯示REST樣式的某些方面的API，或者與REST有更多共同點而不是類似RPC的API。REST本身早於Web API的興起，並且在將Web / Web應用程式的REST樣式對映到API時可能會遇到一些困難。
通常，Web-API被稱為RESTful API，這意味著那些符合REST架構風格強加的大部分或全部約束的API 。

GraphQL
2015年1月，Facebook宣佈其內部客戶端API正在建立在一項名為GraphQL的新技術上（儘管自2011年以來它一直處於開發形式）。這是一個API框架，它用了點RPC模型，以及用了點REST及其對Web協議，但也向自己的方向發展。
GraphQL基於型別模式，其中資料型別及其之間的關係使用介面描述語言（IDL，也稱為模式描述語言或SDL）建模，並且此資訊可由客戶端動態查詢，使用所謂的內省查詢。
GraphQL不是像RPC那樣具有固定功能，也不是像REST那樣可以透過URL訪問的固定資源表示，而是一種概念上與結構化查詢語言（SQL）類似的查詢語言，它允許客戶端僅請求執行任務所需的資料。 ，有時避免多次API呼叫來獲取所需的所有資料。GraphQL還可以批次和組合查詢。GraphQL將查詢分為僅讀取資料的查詢和可以更改資料的查詢，稱為“突變”。
這是一個GraphQL查詢的示例，它使用的語法有點類似於JSON：

{ allPeople { people { name, homeworld { name }}}}


以及JSON中的響應：

{
  "data": {
    "allPeople": {
      "people": [
        {
          "name": "Luke Skywalker",
          "homeworld": {
            "name": "Tatooine"
          }
        },
        {
          "name": "C-3PO",
          "homeworld": {
            "name": "Tatooine"
          }
        },
        {
          "name": "R2-D2",
          "homeworld": {
            "name": "Naboo"
          }
        }
      ]
    }
}


這種方法存在一些潛在的效能缺點，因為在HTTP級別快取GraphQL查詢很困難，並且客戶端可能會發出以前從未見過或經過充分測試的查詢。
還有一種觀點認為，GraphQL的型別系統鼓勵底層資料模型（例如SQL資料庫模式）與呈現給客戶端的資料模型之間更緊密的耦合（儘管情況並非總是這樣）。
Facebook GraphQL堆疊提供了一個名為GraphiQL（發音為'graphical'）的互動式控制檯。其他組織提供GraphQL的實現（例如開源Apollo框架），並且GraphQL由GitHub，Shopify和Yelp等組織公開使用。

GRPC
近年來，API的RPC風格以谷歌gRPC的形式出現了一些復甦（'g'代表gRPC，以遞迴縮寫的形式出現，而不是谷歌）。
gRPC專注於效能，你可以想象谷歌系統交換的資料量，並強制要求使用HTTP / 2。訊息由Protocol Buffers（protobuf）介面描述語言定義，該語言具有文字/人類可讀和二進位制序列化。生成協議緩衝區格式並將資料序列化為協議緩衝區格式的程式碼通常使用protoc編譯器從protobuf IDL生成，從而形成緊湊且高效能的表示，儘管在文字傳輸協議（如HTTP /）的情況下不能輕易檢查1.x的

相關文章