[阅读: 317] 2009-06-09 12:43:08
Quote from "Beautiful Architecture"
请考虑这个地址: http://server/getemployees&type=salaried. 许多人会认为创建这样的地址就是在采用REST。不幸的是,这不是一个好的REST服务名称(大多数“拉斯塔法里分子(Rastafarians) ”会说这根本不是REST!),因为它混合了名词和动词。这就是我常说的“通过URL来寻址行为”或“通过URL来实现RPC”。用REST的方式来区分名词和动词没有什么神奇的,它只是能让我们识别我们关心的事物。前面提到的URL不能够用于更新雇员列表,因为POST一条雇员记录到“/getemployees”没有什么意义。相反,如果URL是http://server/employee/salaried,那么向它发起GET请求将得到相同的信息,而它将成为“领薪雇员”这个业务概念的长期有效地址,正如 http://server/employee/hourly 可以指按小时付薪的所有雇员一样。我们可以选择不更新这些信息资源,因为它们代表的是对后台数据库的查询。但是,在/employee信息空间内是一致的,我们可以选择通过其他方式来导航。http://server/employee/12345678 代表了一个具有特定ID的雇员,而http://server/employee 可能代表所有的雇员。向后面一个URL POST一条记录可以代表雇佣了某人。向包含具体雇员ID的URL PUT一条记录可以代表在岗位变更、升职或加薪之后更新雇员记录。向该地址发出DELETE请求可以表示这个命名资源在该组织机构中已经不再感兴趣了(他们或者辞职,或者被解雇了)。
这突出了REST和SOAP之间的一个主要区别,如果人们混淆了这两种方式的意图,就会导致困惑。REST是关于信息管理的,而不一定是通过URL来调用任意的行为。当人们开始挠头思考4个动词是否足够完成他们想做的事情时,他们想的也许不是信息,他们是在想调用的行为。如果您打算通过URL来实现RPC,你也可以使用SOAP。如果您将重要的业务概念作为可以寻址的信息资源,并且可以在不同环境下进行操作或表示为不同的形式,那么您就在利用REST的长处,可能看到我们在Web上看到的某些好处。即使您的后台系统使用SOAP来满足请求,您也可以设想RESTful接口带来的好处。提供这样的地址不仅让用户能够“在数据上冲浪”,还可以引入缓存结果的能力,消除变更WSDL协议所带来的某些痛苦。客户端会通过一些逻辑连接,再翻译成SOAP消息,然后生成响应结果。响应的内容可以从返回的信息中抽取出来。我们根本不需要宣传这一事实,就能够在这个过程中实现架构迁移的策略。