WebService的两种方式SOAP和REST比较

从目前的两种技术发展来看，两种方法都是webservice( RPC ) 的实现，调用一个接口，然后取得一些参数，进行跨系统的通信。

从标准上看，REST是一种思想，在http(s)上套了一些操作守则；而SOAP是带有强规范 WS-(X) 的标准。

所以，SOAP肯定会有相应的软件组件来构建、验证监测webservice，而REST的实现就五花八门了，其实现在很多大公司的OPEN API ，很多都像是在SOAP的基础上改造的，不大符合REST的思想。

Flickr:
请求消息：

http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value

　　这里就可以很明显看出它所定制的REST请求其实和RPC没有什么太大的区别。

消息返回：
　　正确处理返回

<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="ok">
[xml-payload-here]
</rsp>

　　错误处理返回

<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="fail">
<err code="[error-code]" msg="[error-message]" />
</rsp>

根据返回可以看出已经违背了REST的思想，还是把Http协议作为传输承载协议，并没有真正意义上使用Http协议作为资源访问和操作协议。
总的来说，只是形式上去模仿REST，自己搞了一套私有协议。

Yahoo Maps：
请求消息：

采用REST推荐的方式，URI+Parameters。

返回消息：

<?xml version="1.0" encoding="UTF-8"?>
<ResultSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:yahoo:maps"
xsi:schemaLocation="urn:yahoo:maps http://local.yahooapis.com/MapsService/V1/GeocodeResponse.xsd">
<Result precision="address">
    <Latitude>37.416384</Latitude>
    <Longitude>-122.024853</Longitude>
    <Address>701 FIRST AVE</Address>
    <City>SUNNYVALE</City>
    <State>CA</State>
    <Zip>94089-1019</Zip>
    <Country>US</Country>
</Result>
</ResultSet>

SOAP的精简xml返回，其他信息，例如出错码等信息由Http协议头来承载。

YouTube：
请求消息：

可以看到对于资源操作的URI定义也是参数的一部分。

返回消息：

<?xml version="1.0" encoding="utf-8"?>
<ut_response status="ok">
    <user_profile>
        <first_name>YouTube</first_name>
        <last_name>User</last_name>
        <about_me>YouTube rocks!!</about_me>
        <age>30</age>
        <video_upload_count>7</video_upload_count>
    </user_profile>
</ut_response>

自定义的类SOAP消息。

Amazon：
请求消息：

       https://Amazon FPS web service end point/?AWSAccessKeyId=Your AWSAccessKeyId
      &Timestamp=[Current timestamp] &Signature=[Signature calculated from hash of Action and Timestamp]
      &SignatureVersion=[Signature calculated from hash of Action and Timestamp]
      &Version=[Version of the WSDL specified in YYYY-MM-DD format] &Action=[Name of the API]
      &parameter1=[Value of the API parameter1] &parameter2=[Value of the API parameter2]
      &...[API parameters and their values]

返回消息：

类似于SOAP的自有协议，消息体中包含了消息状态等附加信息。

总结：

1．基本符合REST标准方式：资源URI定义（资源．操作）+参数。这类设计如果滥用get去处理其他类型的操作，那么和2无异。

2． REST风格非REST思想：资源URI定义+参数（包含操作方法名）。其实就是RPC的REST跟风。

3．类似于SOAP消息，自定义协议，以xml作为承载。（可扩展，例如鉴权，访问控制等），不过那就好比自己定义了一套SOAP和SOAP extends。大型的有实力的网站有的采取此种做法。