一、現狀：

前天與後端開發人員討論了API介面的設計。有以下三種方案：

• 1、原始HTTTP協議
  HTTP狀態碼就是該Request的狀態碼，不應該與後端業務混在一起（這也是一部分人使用該方案的理由）。比如200表示該Request成功了，具體業務有沒有操作成功還需要在response body裡再標記，比如1表示操作成功，0表示操作失敗。

• 2、HTTP協議 RESTful 風格
  充分利用HTTP狀態碼，比如200就是該操作成功，定義一個5xx表示業務操作失敗，如果該業務失敗有多種情況則在response body裡再標記。

• 3、SOAP

三者都可以實現，當然是推薦使用2，現在各大網路框架和大的開發平臺API 基本都是這樣的。

二、RESTful 中http code 設計

• 1、標準的200的含義
  請求已成功，請求所希望的響應頭或資料體將隨此響應返回。這句話的意思不就是業務操作成功嘛。

• 2、RESTful 對200 多了一條要求：冪等性
  冪等的意思是請求成功執行所得到的的結果不依賴於該方法被執行的次數。也就是說如果HTTP狀態碼是200，那麼reponse body的報文結構應該只有一種。

三、RESTful 優點

• 1．面向資源的介面設計
  所有的介面設計都是針對資源來設計的，也就很類似於我們的面向物件和麵向過程的設計區別，只不過現在將網路上的操作實體都作為資源來看待，同時URI的設計也是體現了對於資源的定位設計。這樣更符合自然語義。簡化了開發者的不良設計。例如DELETE /zoos/ID：刪除某個動物園 200 就是刪除成功，非200就是 刪除失敗。符合自然語義。使得客戶端的處理邏輯變得簡單。

• 2．抽象操作為基礎的CRUD

  這點很簡單，Http中的get,put,post,delete分別對應了read,update,create,delete四種操作，最大限度的利用了Http最初的應用協議設計理念。

• 3．Http是應用協議而非傳輸協議
  SOAP協議對於訊息體和訊息頭都有定義，訊息頭的可擴充套件性高，但是也由於SOAP由於各種需求不斷擴充其本身協議的內容，導致在SOAP處理方面的效能有所下降。同時在易用性方面以及學習成本上也有所增加。 SOAP 把HTTP當做傳輸層來使用了，自己封裝了一套應用協議。而RESTful 本身不是協議，是一種HTTP協議的使用規範，使得HTTP協議就是作為應用層來使用。簡潔易用。

四、RESTful vs JSON-RPC

JSON-RPC是一個無狀態且輕量級的遠端過程呼叫(RPC)協議。 本規範主要定義了一些資料結構及其相關的處理規則。它允許執行在基於socket,http等諸多不同訊息傳輸環境的同一程序中。其使用JSON（RFC 4627）作為資料格式。

Web Service 也提出了好久了, 那麼究竟什麼是 Web Service ?

簡單地說, 也就是伺服器如何向客戶端提供服務.

常用的方法有:

RPC 所謂的遠端過程呼叫 (面向方法)
SOA 所謂的面向服務的架構(面向訊息)
REST 所謂的 Representational state transfer (面向資源)

JSON-RPC協議描述

json-rpc協議非常簡單，發起遠端呼叫時向服務端傳輸資料格式如下：

{ “method”: “sayHello”, “params”: [“Hello JSON-RPC”], “id”: 1}

引數說明：

method： 呼叫的方法名

params： 方法傳入的引數，若無引數則傳入 []

id ： 呼叫識別符號，用於標示一次遠端呼叫過程

伺服器其收到呼叫請求，處理方法呼叫，將方法效用結果效應給呼叫方；返回資料格式：

{
“result”: “Hello JSON-RPC”,
“error”: null,
“id”: 1
}