趣談網路協議---基於JSON的RESTful介面協議：我不關心過程，請給我結果
SOAP 過於複雜，設計是面向動作的，往往因為架構問題導致併發量上不去。
RESTful 是一種架構模式，主要面向資源，提供無狀態服務，有利於橫向擴充套件應對高併發。
傳輸協議問題
傳輸協議問題—基於 HTTP。
對於 SOAP，建立一個訂單，用 POST 動作，在 XML 中寫明動作是 CreateOrder。其實可以簡化，直接用 POST 動作，然後在 XML 中放一個訂單 ID 即可。
於是 SOAP 可簡化為
POST /purchaseOrder HTTP/1.1 Host: www.geektime.com Content-Type: application/xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <order> <date>2018-07-01</date> <className> 趣談網路協議 </className> <Author> 劉超 </Author> <price>68</price> </order>
而 XML 格式也可改成另一種簡單的文字化的物件表示格式 JSON。
POST /purchaseOrder HTTP/1.1
Host: www.geektime.com
Content-Type: application/json; charset=utf-8
Content-Length: nnn
{
"order": {
"date": "2018-07-01",
"className": " 趣談網路協議 ",
"Author": " 劉超 ",
"price": "68"
}
}
協議約定問題
協議約定問題—基於JSON。
RESTful，是一種架構風格，全稱 Representational State Transful，表述性狀態轉移。
客戶端和服務端誰來維護狀態？狀態是指對某個資料當前處理到什麼程度了。
很多 SOAP 介面是按照服務端維護狀態模式設計的，不適用於有太多客戶端同時連線的場景。
解決：服務端只記錄資源的狀態，由客戶端維護會話的狀態。比如，客戶端想訪問下一頁，先檢視自己當前訪問到哪一頁，是 100~110 頁，然後告訴服務端想訪問 110~120 頁。
對於服務端，只有資源的狀態改變了，客戶端才呼叫 POST、PUT、DELETE 方法；如果資源狀態沒變，只是客戶端的狀態變了，對於服務端而言都是 GET。雖然只改進了 GET，但帶來很大進步，因為對於網際網路應用，大多是讀多寫少的，這也為快取提供了方便。
對於 API 的設計，慢慢變成以資源為核心，而非以過程為核心。這種 API 的設計需實現冪等，因為網路不穩定，經常出錯，需要重試，但同一個呼叫，多次呼叫的結果應該一樣。如 cd a，不能因為重試了 3 次，就變成 cd a/a/a。
RESTful API 和 SOAP API 都可以將架構實現成無狀態，面向資源的、冪等的、橫向擴充套件的、可快取的。但 SOAP 的 XML 正文中，可以放任何動作，如 ADD、MINUS 等，而RESTful 正文裡的 JSON 基本描述的就是資源的狀態，沒辦法描述動作，發出的動作只有 CRUD，即 POST、GET、PUT、DELETE，是對於狀態的改變，從介面的角度提供了保障。
服務發現問題
有個著名的基於 RESTful API 的跨系統呼叫框架叫 Spring Cloud，在 Spring Cloud 中有一個元件叫 Eureka，是用來實現註冊中心，負責維護註冊的服務列表。
服務分服務提供方，它向 Eureka 做服務註冊、續約和下線等操作，註冊的資料包括服務名、機器 IP、埠號、域名等。為實現負責均衡和容錯，服務提供方可以註冊多個。
另外一方是服務消費方，向 Eureka 獲取服務提供方的註冊資訊。消費方呼叫服務時，採用 RESTful 方式。Spring Cloud 提供要給 RestTemplate 工具，將請求物件轉換為 JSON，併發起 Rest 呼叫，RestTemplate 的呼叫分 POST、PUT、GET、DELETE，結果返回時，根據返回的 JSON 解析成物件。