使用Flash构建RESTful服务

Flash已经成为众多流行站点的宠儿，但对其的批评之声依然不绝于耳。从目前来看，虽说Flash已经得到了广泛的应用，但要想以RESTful的方式使用Flash似乎不是那么容易的事情。毫无疑问，Flash浏览器只支持GET与POST操作，不允许通过POST模拟PUT与DELETE，此外还没法处理cookies（请参考这篇文章：REST反模式）。幸运的是，OASIS SOA Reference Model TC的联席主席与Adobe布道者Duane Nickull就这篇文章谈到了自己的一些观点。

\

Flash拥有良好的架构，与OASIS Reference Model for SOA所定义的SOA核心原则（该原则是个抽象模型，描述了SOA的核心原则，它与Roy Fielding关于REST的博士论文具有同样的抽象级别）是一致的。Flash也与REST的核心原则保持一致。

\

Duane等人指出：REST并非只限定于HTTP。我们完全可以使用其他技术设计RESTful服务与应用。接下来，Duane解释了他为何认为只应该支持GET与POST的原因所在，这与基本的SOA需求息息相关：

\

以SOA方式架构应用的目的是在可能的情况下将数据管理从传输工作中脱离出来，同时保持前者的语义。这么做的规则其实并不难制订，与我交流过的很多架构师都相信这才是最好的构建方式。每个服务都有一个与之关联的数据模型与动作模型来处理服务调用。数据模型就是数据，处理/动作模型可以表达服务调用的“动词”。

\

在理想的情况下，架构中的每个层次都应该独立于其他层次，这也是W3C Web Services Architecture工作组选择在SOAP中只支持GET与POST的原因所在；同时，这也是Flash只支持有限动词的一个原因。为了证明自己的观点，Duane引用了Roy Fielding的论文（参见6.3节），这一节开始是这样说的：

\

REST所指出的HTTP的主要问题域包括新协议版本的部署规划、将HTTP语义与底层传输层（TCP）的消息解析分离开来、识别授权与非授权的响应、细粒度的缓存控制、缺乏自我描述能力的协议的方方面面等。REST还用于模拟基于HTTP的Web应用的性能，预测持续连接与内容协商等扩展所产生的影响。最后，REST用于将标准化HTTP扩展的范围限制到适合的架构模型当中，而不会让误用HTTP的应用影响到标准。

\

接下来Duane说，不管使用REST还是SOA，架构师都希望使用GET与POST。比如说，考虑DELETE：它意味着将非常特定的语义（可能压根就不可用）公开给特定服务器的所有消费者（非认证）。

\

如果你希望将其公开给服务的消费者，那么我建议你再去构建一个服务以实现该目的，但要保持后端的处理语义（很多情况下指的是SOAP体）。

\

关于PUT与POST的争论持续了很长时间，Duane就此说到：

\

有些人认为PUT等价于SQL中的INSERT，POST等价于CREATE。虽然在某种程度上这种说法没错，但在实际情况下，这两个操作所涉及的字节数都超过了现有的资源拷贝，因此它实际上相当于CRUD中的UPDATE。

\

值得注意的是，PUT并非是RESTful的必要组成部分。最后，之前有文章谈过关于cookies的问题。Stefan Tilkov介绍了一系列的REST反模式，cookies就是其中之一，至少在没有正确使用好cookies的情况下是这样的。

\

如果使用了cookies，那就说明某处一定不是RESTful，对么？不一定。REST的一个关键点就是无状态——这并不是说服务器不能存储任何数据，如果存在资源状态或是客户端状态也是可以的。由于可伸缩性、可靠性以及解耦等原因，不允许有会话状态。cookies最典型的使用情况是存储键，键指向了某些位于内存中的服务器端数据结构。这意味着浏览器每次发送请求时都会携带的cookies是用于建立会话状态的。如果cookie存储了某些信息，比如认证令牌（服务器端可以不用借助于会话状态就能实现验证），那么cookies就完全是RESTful的，但有一点需要注意：他们不应该用于编码可由其他更加标准的方式（比如说在URI中，某些标准的头，或是在消息体当中，不过这种情况比较少见）所传输的信息。例如，从RESTful HTTP的视角来看，我们推荐使用HTTP认证。

\

总之，Duane认为SOA与REST通常都是合作良好的搭档。借助于运行期对正确功能级别的支持，Flash的架构完全遵循REST与SOA的核心原则，也就是说，我们完全可以使用Flash开发RESTful服务。

\

查看英文原文：Building RESTful services with Flash