Web 服务
随着业务的发展,用户量的增加,有很多系统需要将不同的业务功能部署在不同的计算机上,这样也就引发了一个新的问题,怎样在多个计算机进行交互?怎样让一个业务整体分散在不同的计算机上执行?怎样进行远程调用?web服务是一种服务导向架构的技术,通过标准的Web协议提供服务,目的是保证不同平台的应用服务可以互操作。
Web服务实际上是一组工具,并有多种不同的方法调用之。三种最普遍的手段是:
远程过程调用(RPC)
服务导向架构(SOA)
以及表述性状态转移(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的软件依赖性更小
不需要额外的资源发现机制
在软件技术演进中的长期的兼容性更好
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。