2012-10-31 87 views
6

我正在一個項目中嘗試公開該軟件的功能。基本上我有我的後端設置,並正在考慮使用JSON消息從後端代碼分離前端。對於服務和API之間的區別,我有點困惑。我知道API可以建立在服務之上。但我有這兩種模式 - 訪問配置文件X使用json-rpcWeb服務 - REST vs PHP JSON RPC

http://xyz.com/?request= {「jsonrpc」:「2.0」,「id」:1,「method」:「getProfile」,「params」: { 「ID」: 「X」}}

或者它應該是這樣使用REST -

http://api.xyz.com/X

謝謝

+1

在這裏你有一個比較http://stackoverflow.com/questions/1098473/rest-vs-rpc – Chuidiang

+0

如果你想RPC使用SOAP。否則REST。 –

回答

20

「服務」與「API」是一個非常模糊的問題。通常,這兩個術語可以互換使用。 「REST」與「RPC」有點容易解釋。

通常使用REST,URL表示特定資源,例如「用戶」,「帳戶」等。通常,您可以使用HTTP方法POST/GET創建/檢索/更新/刪除這些資源/ PUT/DELETE。要更新用戶1125配置文件,你可以發送以下:你想與用戶1125做

POST /user/1125 HTTP/1.1 
Host: wherever.com 
Content-type: application/x-www-form-urlencoded 

firstName=Davey&lastName=Jones&email=dj%40thebrineydeep.com 

任何事情,你會發送到同一個URL的請求。這個想法有例外和變種,但這是它的關鍵。

RPC服務更像是使用函數庫,它綁定到特定的URL。你可能有一大堆相關的功能都綁定在URL /services/json上。這時如果你想改變天寒老戴維·瓊斯,你會:

POST /services/json HTTP/1.1 
Host: wherever.com 
Content-type: application/json 

{ "jsonrpc": "2.0", 
    "id": 1, 
    "method": "setProfile", 
    "params": [ 1125, 
    { "firstName": "Davey", 
     "lastName": "Jones", 
     "email": "[email protected]" 
    } 
    ] 
} 

我個人很喜歡JSON-RPC更好,因爲:

  • 我沒有嘗試適合所有的我函數調用某種資源到URL映射可能沒有意義
  • 我們不嘗試重載HTTP響應代碼以指示API錯誤。每個請求都會返回一個200響應(除非存在服務器錯誤),並且您從響應主體瞭解您是否遇到錯誤。 JSON-RPC特別擅長明確錯誤條件。

有時REST是更好,因爲:

  • 有時資源到URL映射配合得很好
  • 更直觀的第三方理解
  • 它提供了一個簡單的模型只是檢索容易識別的信息

我不認爲任何人都更容易編碼。

編輯我更改了REST示例以使用更常見的表單編碼數據而不是JSON。但是,您當然可以使用REST指定您喜歡的任何數據格式。它不是刻在石頭上。

+0

感謝您的回覆..在rpc服務周圍創建一個「REST包裝器」是否有意義...如果您正在訪問用戶配置文件「user1」,那麼用戶將鍵入 - 「http://xyz.com/user1「..這會在內部調用rpc-service來獲取id爲」user1「的資源? – Fox

+0

這是可行的,只要你有一個從REST <-> RPC的簡單映射。即便如此,這是額外的工作。你必須問自己,你必須從中獲得什麼。我通常會只用一個或另一個去。 – slashingweapon

0

您的REST URL不等於你的JSON-RPC請求。

至少它應該是http://api.example.org/getProfile?id=X

真的是沒有兩者太大的差別。除非您返回的數據格式可以可靠地表示指向不同網址的鏈接,例如,您的「REST」不是真正的REST。 XML或(X)HTML。在滿足這個要求之前,你只能稱它爲「RESTful」,因爲你實際上只使用HTTP方法來觸發內容並來回移動數據。

使用什麼並不重要 - 除非您知道或有使用軟件的經驗,可以幫助您更快速地構建其中一種或另一種解決方案。