SOAPvsREST_WebService

这点其实不仅仅是对于

REST

来说的，

作为接口设计都需要能够做到这点，

也是作为可扩展

和高效性的最基本的保证，就算是使用

SOAP

的

WebService

也是一样。

 

REST vs SOAP 

成熟度：

 

SOAP

虽然发展到现在已经脱离了初衷，

但是对于异构环境服务发布和调用，

以及厂商的支

持都已经达到了较为成熟的情况。

不同平台，

开发语言之间通过

SOAP

来交互的

web service

都能够较好的互通

（在部分复杂和特殊的参数和返回对象解析上，

协议没有作很细致的规定，

导致还是需要作部分修正）

 

REST

国外很多大网站都发布了自己的开发

API

，很多都提供了

SOAP

和

REST

两种

Web 

Service

，根据调查部分网站的

REST

风格的使用情况要高于

SOAP

。但是由于

REST

只是一

种基于

Http

协议实现资源操作的思想，因此各个网站的

REST

实现都自有一套，在后面会

讲诉各个大网站的

REST API

的风格。也正是因为这种各自实现的情况，在性能和可用性上

会大大高于

SOAP

发布的

web service

，

但统一通用方面远远不及

SOAP

。

由于这些大网站的

SP

往往专注于此网站的

API

开发，因此通用性要求不高。

 

ASF

上考虑发布

REST

风格的

Web 

Service

，可以参考几大网站的设计（兄弟公司的方案就

是参考了类似于

flickr

的设计模式）

，但是由于没有类似于

SOAP

的权威性协议作为规范，

REST

实现的各种协议仅仅只能算是私有协议，当然需要遵循

REST

的思想，但是这样细节

方面有太多没有约束的地方。

REST

日后的发展所走向规范也会直接影响到这部分的设计是

否能够有很好的生命力。

 

总的来说

SOAP

在成熟度上优于

REST

。

 

效率和易用性：

 

       

SOAP

协议对于消息体和消息头都有定义，

同时消息头的可扩展性为各种互联网的标准

提供了扩展的基础，

WS-*

系列就是较为成功的规范。但是也由于

SOAP

由于各种需求不断

扩充其本身协议的内容，导致在

SOAP

处理方面的性能有所下降。同时在易用性方面以及

学习成本上也有所增加。

 

       

REST

被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效

一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，

同时也最大限度的

利用了

Http

最初的应用协议设计理念。同时，在我看来

REST

还有一个很吸引开发者的就

是能够很好的融合当前

Web2.0

的很多前端技术来提高开发效率。例如很多大型网站开放的

REST

风

格

的

API

都

会

有

多

种

返

回

形

式

，

除

了

传

统

的

xml

作

为

数

据

承

载

，

还

有

（

JSON,RSS,ATOM

）等形式，这对很多网站前端开发人员来说就能够很好的

mashup

各种

资源信息。

 

       

因此在效率和易用性上来说，

REST

更胜一筹。

 

安全性：

 

       

这点其实可以放入到成熟度中，不过在当前的互联网应用和平台开发设计过程中，安全

已经被提到了很高的高度，

特别是作为外部接口给第三方调用，

安全性可能会高过业务逻辑

本身。

 

       

SOAP

在安全方面是通过使用

XML-Security

和

XML-Signature

两个规范组成了

WS-Security

来实现安全控制的，当前已经得到了各个厂商的支持，

.net 

，

PHP 

，

java 

都已经

对其有了很好的支持

（虽然在一些细节上还是有不兼容的问题，

但是互通基本上是可以的）

。

 

       

REST

没有任何规范对于安全方面作说明，

同时现在开放

REST

风格

API

的网站主要分

成两种，一种是自定义了安全信息封装在消息中（其实这和

SOAP

没有什么区别）

，另外一

种就是靠硬件

SSL

来保障

,

但是这只能够保证点到点的安全，如果是需要多点传输的话

SSL

就无能为力了。安全这块其实也是一个很大的问题，今年在

BEA

峰会上看到有演示采用

SAML2

实现的网站间

SSO

，其实是直接采用了

XML-Security

和

XML-Signature

，效率看起

来也不是很高。

未来

REST

规范化和通用化过程中的安全是否也会采用这两种规范，

是未知

的，但是加入的越多，

REST

失去它高效性的优势越多。

 

应用设计与改造：

 

       

我们的系统要么就是已经有了那些需要被发布出去的服务，要么就是刚刚设计好的服

务，

但是开发人员的传统设计思想让

REST

的形式被接受还需要一点时间。

同时在资源型数

据服务接口设计上来说按照

REST

的思想来设计相对来说要容易一些，

而对于一些复杂的服

务接口来说，

可能强要去按照

REST

的风格来设计会有些牵强。

这一点其实可以看看各大网

站的接口就可以知道，很多网站还要传入

function

的名称作为参数，这就明显已经违背了

REST

本身的设计思路。

 

       

而

SOAP

本身就是面向

RPC

来设计的，开发人员十分容易接受，所以不存在什么适应

的过程。

 

总的来说，其实还是一个老观念，适合的才是最好的

 

       

技术没有好坏，

只有是不是合适，

一种好的技术和思想被误用了，

那么就会得到反效果。

REST

和

SOAP

各自都有自己的优点，同时如果在一些场景下如果去改造

REST

，其实就会

走向

SOAP

（例如安全）

。

 

       

REST

对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安

全要求不高的场景。而

SOAP

的成熟性可以给需要提供给多开发语言的，对于安全性要求

较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意

义，关键还是看应用场景。

 

       

同时很重要一点就是不要扭曲了

REST

现在很多网站都跟风去开发

REST

风格的接口，

其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了，徒有一

个看似象摸象样的皮囊。

 

REST

设计的几种形式

 

参看了几个大型网站的

REST

风格的

API

设计，这里做一下大致的说明：

 

FaceBook:

 

请求消息：

 

       

在

URI

设计上采取了类似于

REST

的风格。

例如对于

friends

的获取，

就定义为

friends.get

，

前面部分作为资源定义，后面是具体的操作，其他的

API

也是类似，资源

+

操作，因此就算

使用

http

的

get

方法都可能作了

update

的操作，其实已经违背了

REST

的思想，但是说到，

其实那么复杂的业务接口设计下，

要通过

RUCD

来抽象所有的接口基本是不实际的。

在

URI

定义好以后，还有详细的参数定义，包括类型以及是否必选。

 

响应消息：

 

       

有多种方式，

XML,JSON

。

XML

有

XSD

作为参考。有点类似于没有

Head

的

SOAP

，

只

不过这里将原来可以定义在

WSDL

中的

XSD

抽取出来了。

 

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

，自己搞了一套私有协议。

 

Ebay

：

 

       

请求消息：

 

       

采用

xml

作为承载，类似于

SOAP

，不过去除

SOAP

消息的封装和包头，同时在请求中

附加了认证和警告级别等附加信息。

 

       

消息返回：

 

       

类似于

SOAP

消息，

不过删除了

SOAP

的封装和包头，

同时在返回结构中增加了消息处

理结果以及版本等附加信息。

 

       

这个很类似于当前

Axis2

框架的做法，将

SOAP

精简，同时根据自身需求丰富了安全，

事务等协议内容。

 

Yahoo Maps

：

 

       

请求消息：

 

       

http://local.yahooapis.com/MapsService/V1/geocode?appid=YahooDemo&street=701+First+

Ave&city=Sunnyvale&state=CA

 

       

采用

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 A

VE</Address> 

    

<City>SUNNYV

ALE</City> 

    

<State>CA</State> 

    

<Zip>94089-1019</Zip> 

    

<Country>US</Country> 

 </Result> 

</ResultSet> 

SOAP

的精简

xml

返回，其他信息，例如出错码等信息由

Http

协议头来承载。

 

YouTube

：

 

请求消息：

 

http://www.youtube.com/api2_rest?method=youtube.users.get_profile&dev_id=YOUR_DEV_ID

&user=YOUTUBE_USER_NAME

 

可以看到对于资源操作的

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

。大型的有实力的网站有的采取此种

做法。

 

响应消息设计：

 

1.       REST

标准方式，将

Resource State

传输返回给客户端，

@H_342_1404@Http

消息作为应用协议而非传

输协议

 

2.       

以

XML

作为消息承载体，

@H_342_1404@Http

作为消息传输协议，处理状态自包含。

 

3.       

自定义消息格式，类似于

SOAP

，提供可扩展部分。

 

作为遵循

REST

的理念来看我的选择是响应

1

和请求

1

的设计。

 

REST

和

ASF

的集成

 

ASF

要集成

REST

就现在来看有两种比较合适的方法。

 

一．就是采用

Axis2

的

REST

实现，这种方式的好处就是开发周期短，容易集成，但是请求

和响应的格式无法改变，资源

URI

设计受限，

Axis2

的

REST

其实就是将

SOAP

消息精简，

请求的时候删除了

SOAP

的头，

响应的时候仅仅返回资源信息，

如果提供

xsd

就可以被各种

客户端所解析。并非真正的

REST

。

 

二．就是采用

Restlet

开源框架，将

Restlet

开源框架集成到

ASF

中，由于

Restlet

本身就是

可内嵌的应用框架，因此集成不成问题，同时

Restlet

框架只是

API

结构框架，因此实现和

定义完全分开，

集成

Restlet

以后可以自己实现其中的解析引擎也可以采用默认提供的引擎，

同时对于内嵌

Jetty

等多种开源项目的支持，将更多优势融入到了

Rest

中。看了一下国内也

有很多朋友已经关注

Restlet

开源项目，看了它的架构设计，个人觉得还是比较灵活和紧凑

的。

 

题外话

 

       

在写这篇文章以前写了一篇调研报告群发给各个架构师们参考，期待反馈。下午正好和

我们的首席架构师聊了一会儿。其实我和他的感觉是一样的，

REST

是否真的在我们现有的

服务框架中需要集成，

理解了

REST

的思想再去看应用场景，

那么可以发现如果要完全遵循

REST

的设计理念来设计接口的话，

那么强要去改变现有已经存在的或者还未开发的接口就

会落入为了技术而技术，

为了潮流而跟风的近地。

当然并不否认

REST

的好，

其实我们兄弟

公司的一些业务场景有部分的接口十分合适这类设计，面向资源，

高效，

简洁，易用都能够

体现出它的价值。

我们将会和我们的兄弟公司合作，

也会参考他们的设计理念，

在参考当前

各个网站的实现情况下，部分的采用这类形式的发布，提供给第三方的

ISV

，无疑是我现在

把

REST

融入到

ASF

中最好的理由。

 

       

有了需求去做才不会陷入为了技术而技术，毕竟技术是由商业价值驱动的，同样社会上

充斥着各种技术的鼓吹，如果稍不留神就会陷入跟风的潮流中。

这点其实不仅仅是对于

REST

来说的，

作为接口设计都需要能够做到这点，

也是作为可扩展

和高效性的最基本的保证，就算是使用

SOAP

的

WebService

也是一样。

 

REST vs SOAP 

成熟度：

 

SOAP

虽然发展到现在已经脱离了初衷，

但是对于异构环境服务发布和调用，

以及厂商的支

持都已经达到了较为成熟的情况。

不同平台，

开发语言之间通过

SOAP

来交互的

web service

都能够较好的互通

（在部分复杂和特殊的参数和返回对象解析上，

协议没有作很细致的规定，

导致还是需要作部分修正）

 

REST

国外很多大网站都发布了自己的开发

API

，很多都提供了

SOAP

和

REST

两种

Web 

Service

，根据调查部分网站的

REST

风格的使用情况要高于

SOAP

。但是由于

REST

只是一

种基于

Http

协议实现资源操作的思想，因此各个网站的

REST

实现都自有一套，在后面会

讲诉各个大网站的

REST API

的风格。也正是因为这种各自实现的情况，在性能和可用性上

会大大高于

SOAP

发布的

web service

，

但统一通用方面远远不及

SOAP

。

由于这些大网站的

SP

往往专注于此网站的

API

开发，因此通用性要求不高。

 

ASF

上考虑发布

REST

风格的

Web 

Service

，可以参考几大网站的设计（兄弟公司的方案就

是参考了类似于

flickr

的设计模式）

，但是由于没有类似于

SOAP

的权威性协议作为规范，

REST

实现的各种协议仅仅只能算是私有协议，当然需要遵循

REST

的思想，但是这样细节

方面有太多没有约束的地方。

REST

日后的发展所走向规范也会直接影响到这部分的设计是

否能够有很好的生命力。

 

总的来说

SOAP

在成熟度上优于

REST

。

 

效率和易用性：

 

       

SOAP

协议对于消息体和消息头都有定义，

同时消息头的可扩展性为各种互联网的标准

提供了扩展的基础，

WS-*

系列就是较为成功的规范。但是也由于

SOAP

由于各种需求不断

扩充其本身协议的内容，导致在

SOAP

处理方面的性能有所下降。同时在易用性方面以及

学习成本上也有所增加。

 

       

REST

被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效

一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，

同时也最大限度的

利用了

Http

最初的应用协议设计理念。同时，在我看来

REST

还有一个很吸引开发者的就

是能够很好的融合当前

Web2.0

的很多前端技术来提高开发效率。例如很多大型网站开放的

REST

风

格

的

API

都

会

有

多

种

返

回

形

式

，

除

了

传

统

的

xml

作

为

数

据

承

载

，

还

有

（

JSON,ATOM

）等形式，这对很多网站前端开发人员来说就能够很好的

mashup

各种

资源信息。

 

       

因此在效率和易用性上来说，

REST

更胜一筹。

 

安全性：

 

       

这点其实可以放入到成熟度中，不过在当前的互联网应用和平台开发设计过程中，安全

已经被提到了很高的高度，

特别是作为外部接口给第三方调用，

安全性可能会高过业务逻辑

本身。

 

       

SOAP

在安全方面是通过使用

XML-Security

和

XML-Signature

两个规范组成了

WS-Security

来实现安全控制的，当前已经得到了各个厂商的支持，

.net 

，

PHP 

，

java 

都已经

对其有了很好的支持

（虽然在一些细节上还是有不兼容的问题，

但是互通基本上是可以的）

。

 

       

REST

没有任何规范对于安全方面作说明，

同时现在开放

REST

风格

API

的网站主要分

成两种，一种是自定义了安全信息封装在消息中（其实这和

SOAP

没有什么区别）

，另外一

种就是靠硬件

SSL

来保障

,

但是这只能够保证点到点的安全，如果是需要多点传输的话

SSL

就无能为力了。安全这块其实也是一个很大的问题，今年在

BEA

峰会上看到有演示采用

SAML2

实现的网站间

SSO

，其实是直接采用了

XML-Security

和

XML-Signature

，效率看起

来也不是很高。

未来

REST

规范化和通用化过程中的安全是否也会采用这两种规范，

是未知

的，但是加入的越多，

REST

失去它高效性的优势越多。

 

应用设计与改造：

 

       

我们的系统要么就是已经有了那些需要被发布出去的服务，要么就是刚刚设计好的服

务，

但是开发人员的传统设计思想让

REST

的形式被接受还需要一点时间。

同时在资源型数

据服务接口设计上来说按照

REST

的思想来设计相对来说要容易一些，

而对于一些复杂的服

务接口来说，

可能强要去按照

REST

的风格来设计会有些牵强。

这一点其实可以看看各大网

站的接口就可以知道，很多网站还要传入

function

的名称作为参数，这就明显已经违背了

REST

本身的设计思路。

 

       

而

SOAP

本身就是面向

RPC

来设计的，开发人员十分容易接受，所以不存在什么适应

的过程。

 

总的来说，其实还是一个老观念，适合的才是最好的

 

       

技术没有好坏，

只有是不是合适，

一种好的技术和思想被误用了，

那么就会得到反效果。

REST

和

SOAP

各自都有自己的优点，同时如果在一些场景下如果去改造

REST

，其实就会

走向

SOAP

（例如安全）

。

 

       

REST

对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安

全要求不高的场景。而

SOAP

的成熟性可以给需要提供给多开发语言的，对于安全性要求

较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意

义，关键还是看应用场景。

 

       

同时很重要一点就是不要扭曲了

REST

现在很多网站都跟风去开发

REST

风格的接口，

其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了，徒有一

个看似象摸象样的皮囊。

 

REST

设计的几种形式

 

参看了几个大型网站的

REST

风格的

API

设计，这里做一下大致的说明：

 

FaceBook:

 

请求消息：

 

       

在

URI

设计上采取了类似于

REST

的风格。

例如对于

friends

的获取，

就定义为

friends.get

，

前面部分作为资源定义，后面是具体的操作，其他的

API

也是类似，资源

+

操作，因此就算

使用

http

的

get

方法都可能作了

update

的操作，其实已经违背了

REST

的思想，但是说到，

其实那么复杂的业务接口设计下，

要通过

RUCD

来抽象所有的接口基本是不实际的。

在

URI

定义好以后，还有详细的参数定义，包括类型以及是否必选。

 

响应消息：

 

       

有多种方式，

XML,JSON

。

XML

有

XSD

作为参考。有点类似于没有

Head

的

SOAP

，

只

不过这里将原来可以定义在

WSDL

中的

XSD

抽取出来了。

 

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

，自己搞了一套私有协议。

 

Ebay

：

 

       

请求消息：

 

       

采用

xml

作为承载，类似于

SOAP

，不过去除

SOAP

消息的封装和包头，同时在请求中

附加了认证和警告级别等附加信息。

 

       

消息返回：

 

       

类似于

SOAP

消息，

不过删除了

SOAP

的封装和包头，

同时在返回结构中增加了消息处

理结果以及版本等附加信息。

 

       

这个很类似于当前

Axis2

框架的做法，将

SOAP

精简，同时根据自身需求丰富了安全，

事务等协议内容。

 

Yahoo Maps

：

 

       

请求消息：

 

       

http://local.yahooapis.com/MapsService/V1/geocode?appid=YahooDemo&street=701+First+

Ave&city=Sunnyvale&state=CA

 

       

采用

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 A

VE</Address> 

    

<City>SUNNYV

ALE</City> 

    

<State>CA</State> 

    

<Zip>94089-1019</Zip> 

    

<Country>US</Country> 

 </Result> 

</ResultSet> 

SOAP

的精简

xml

返回，其他信息，例如出错码等信息由

Http

协议头来承载。

 

YouTube

：

 

请求消息：

 

http://www.youtube.com/api2_rest?method=youtube.users.get_profile&dev_id=YOUR_DEV_ID

&user=YOUTUBE_USER_NAME

 

可以看到对于资源操作的

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

。大型的有实力的网站有的采取此种

做法。

 

响应消息设计：

 

1.       REST

标准方式，将

Resource State

传输返回给客户端，

@H_342_1404@Http

消息作为应用协议而非传

输协议

 

2.       

以

XML

作为消息承载体，

@H_342_1404@Http

作为消息传输协议，处理状态自包含。

 

3.       

自定义消息格式，类似于

SOAP

，提供可扩展部分。

 

作为遵循

REST

的理念来看我的选择是响应

1

和请求

1

的设计。

 

REST

和

ASF

的集成

 

ASF

要集成

REST

就现在来看有两种比较合适的方法。

 

一．就是采用

Axis2

的

REST

实现，这种方式的好处就是开发周期短，容易集成，但是请求

和响应的格式无法改变，资源

URI

设计受限，

Axis2

的

REST

其实就是将

SOAP

消息精简，

请求的时候删除了

SOAP

的头，

响应的时候仅仅返回资源信息，

如果提供

xsd

就可以被各种

客户端所解析。并非真正的

REST

。

 

二．就是采用

Restlet

开源框架，将

Restlet

开源框架集成到

ASF

中，由于

Restlet

本身就是

可内嵌的应用框架，因此集成不成问题，同时

Restlet

框架只是

API

结构框架，因此实现和

定义完全分开，

集成

Restlet

以后可以自己实现其中的解析引擎也可以采用默认提供的引擎，

同时对于内嵌

Jetty

等多种开源项目的支持，将更多优势融入到了

Rest

中。看了一下国内也

有很多朋友已经关注

Restlet

开源项目，看了它的架构设计，个人觉得还是比较灵活和紧凑

的。

 

题外话

 

       

在写这篇文章以前写了一篇调研报告群发给各个架构师们参考，期待反馈。下午正好和

我们的首席架构师聊了一会儿。其实我和他的感觉是一样的，

REST

是否真的在我们现有的

服务框架中需要集成，

理解了

REST

的思想再去看应用场景，

那么可以发现如果要完全遵循

REST

的设计理念来设计接口的话，

那么强要去改变现有已经存在的或者还未开发的接口就

会落入为了技术而技术，

为了潮流而跟风的近地。

当然并不否认

REST

的好，

其实我们兄弟

公司的一些业务场景有部分的接口十分合适这类设计，面向资源，

高效，

简洁，易用都能够

体现出它的价值。

我们将会和我们的兄弟公司合作，

也会参考他们的设计理念，

在参考当前

各个网站的实现情况下，部分的采用这类形式的发布，提供给第三方的

ISV

，无疑是我现在

把

REST

融入到

ASF

中最好的理由。

 

       

有了需求去做才不会陷入为了技术而技术，毕竟技术是由商业价值驱动的，同样社会上

充斥着各种技术的鼓吹，如果稍不留神就会陷入跟风的潮流中。