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]? ?????? ¶meter1=[Value?of?the?API?parameter1]?¶meter2=[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 传输返回给客户端， Http 消息作为应用协议而非传 输协议 ? 2.??????? 以 XML 作为消息承载体， 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]? ?????? ¶meter1=[Value?of?the?API?parameter1]?¶meter2=[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 传输返回给客户端， Http 消息作为应用协议而非传 输协议 ? 2.??????? 以 XML 作为消息承载体， 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 中最好的理由。 ? ??????? 有了需求去做才不会陷入为了技术而技术，毕竟技术是由商业价值驱动的，同样社会上 充斥着各种技术的鼓吹，如果稍不留神就会陷入跟风的潮流中。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |