web service 的一些概念

Web 服務

隨着業務的發展，用戶量的增長，有不少系統須要將不一樣的業務功能部署在不一樣的計算機上，這樣也就引起了一個新的問題，怎樣在多個計算機進行交互？怎樣讓一個業務總體分散在不一樣的計算機上執行？怎樣進行遠程調用？web服務是一種服務導向架構的技術，經過標準的Web協議提供服務，目的是保證不一樣平臺的應用服務能夠互操做。

Web服務其實是一組工具，並有多種不一樣的方法調用之。三種最廣泛的手段是：

1. 遠程過程調用（RPC）

2. 服務導向架構（SOA）

3. 以及表述性狀態轉移（REST）

RPC

RPC 遠程過程調用協議，是一種計算機通訊協議。該協議容許運行於一臺計算機額程序調用另外一臺計算機的子程序，而程序無需額外的爲這個交互編程。RPC通訊協議又有xml-rpc和json-rpc幾種不一樣的實現。

XML-RPC

XML-RPC經過xml形式去封裝函數和返回調用結果,並使用http協議做爲傳送機制。

數組array這樣表示

<array>
  <data>
    <value><i4>1404</i4></value>
    <value><string>Something here</string></value>
    <value><i4>1</i4></value>
  </data>
</array>

請求範例

<?xml version="1.0"?>
<methodCall>
  <methodName>examples.getStateName</methodName>
  <params>
    <param>
        <value><i4>40</i4></value>
    </param>
  </params>
</methodCall>

響應範例

<?xml version="1.0"?>
<methodResponse>
  <params>
    <param>
        <value><string>South Dakota</string></value>
    </param>
  </params>
</methodResponse>

XML-RPC 錯誤：

<?xml version="1.0"?>
<methodResponse>
  <fault>
    <value>
      <struct>
        <member>
          <name>faultCode</name>
          <value><int>4</int></value>
        </member>
        <member>
          <name>faultString</name>
          <value><string>Too many parameters.</string></value>
        </member>
      </struct>
    </value>
  </fault>
</methodResponse>

JSON-RPC

json-rpc是一個無狀態且輕量級的遠程過程調用（RPC）協議。它爲簡單而生，採用json的格式去封裝方法和參數、請求、響應等等,採用http協議做爲傳送機制。

請求範例

{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}

• jsonrpc 指定JSON-RPC協議版本的字符串，必須準確寫爲「2.0」

• method 包含所要調用方法名稱的字符串，以rpc開頭的方法名，用英文句號（U+002E or ASCII 46）鏈接的爲預留給rpc內部的方法名及擴展名，且不能在其餘地方使用。

• params 調用方法所須要的結構化參數值，該成員參數能夠被省略。

• id 已創建客戶端的惟一標識id，值必須包含一個字符串、數值或NULL空值。若是不包含該成員則被認定爲是一個通知。該值通常不爲NULL[1]，若爲數值則不該該包含小數[2]。

響應範例

{"jsonrpc": "2.0", "result": 19, "id": 1}

• result 改爲員在成功時必須包含，當調用錯誤時不能包含。服務端中的被調用方法決定了該成員的值。

• id 該成員值必須於請求對象中的id成員值一致。若在檢查請求對象id時錯誤（例如參數錯誤或無效請求），則該值必須爲空值。

請求出現錯誤時的響應

{"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": "1"}

• code 使用數值表示該異常的錯誤類型。 必須爲整數。

code	message	meaning
-32700	Parse error語法解析錯誤	服務端接收到無效的json。該錯誤發送於服務器嘗試解析json文本
-32600	Invalid Request無效請求	發送的json不是一個有效的請求對象。
-32601	Method not found找不到方法	該方法不存在或無效
-32602	Invalid params無效的參數	無效的方法參數。
-32603	Internal error內部錯誤	JSON-RPC內部錯誤。
-32000 to -32099	Server error服務端錯誤	預留用於自定義的服務器錯誤。

• message 對該錯誤的簡單描述字符串。 該描述應儘可能限定在簡短的一句話。

• data 包含關於錯誤附加信息的基本類型或結構化類型。該成員可忽略。 該成員值由服務端定義（例如詳細的錯誤信息，嵌套的錯誤等）。

SOA

SOA（服務導向的架構）在宏觀（服務）上，而不是在微觀上（對象）所以提升了重複使用性。同時，服務導向的架構能夠簡化與傳統系統的互連和使用。

與RPC不一樣，SOA 對服務的註冊發佈、接口的描述、消息的描述分別採用不一樣的標準。

• XML - 一種標記語言，用於以文檔格式描述消息中的數據。

• HTTP（或HTTPS） - 客戶端和服務端之間用於傳送信息而發送請求/回覆的協議。

• SOAP（Simple Object Access Protocol） - 在計算機網絡上交換基於XML的消息的協議，一般是用HTTP。

• WSDL（Web Services Description Language，Web服務描述語言） - 基於XML的描述語言，用於描述與服務交互所需的服務的公共接口，協議綁定，消息格式。

• UDDI（Universal Description, Discovery, and Integration，是統一描述、發現和集成） - 基於XML的註冊協議，用於發佈WSDL並容許第三方發現這些服務。

REST

REST是設計風格而不是標準。REST一般基於使用HTTP，URI，和XML以及HTML這些現有的普遍流行的協議和標準。

複合REST風格的WEB API一般被稱爲 RESTFul API,它從資源地址、資源類型、對資源的操做三個方面對資源進行定義。

• 資源地址：URI，好比：http://example.com/resources/。

• 資源類型：Web服務接受與返回的互聯網媒體類型，好比：JSON，XML，YAML等。

• 對資源的操做：Web服務在該資源上所支持的一系列請求方法（好比：POST，GET，PUT或DELETE）。

REST的優勢

• 可更高效利用緩存來提升響應速度

• 通信自己的無狀態性可讓不一樣的服務器的處理一系列請求中的不一樣請求，提升服務器的擴展性

• 瀏覽器便可做爲客戶端，簡化軟件需求

• 相對於其餘疊加在HTTP協議之上的機制，REST的軟件依賴性更小

• 不須要額外的資源發現機制

• 在軟件技術演進中的長期的兼容性更好