REST设计的8大误区

最新推荐文章于 2019-07-21 19:39:14 发布

hero_yin

最新推荐文章于 2019-07-21 19:39:14 发布

阅读量1.8k

点赞数

分类专栏： REST 文章标签： rest soap service delete action web服务

REST 专栏收录该内容

1 篇文章

订阅专栏

当第一次设计REST系统的时候，人们很容易犯下各种错误。本文对这些错误做个汇总，这样你就可以在设计过程中避免他们。如果有任何不清楚的地方可以在rest讨论版区提问。

没有充分的利用HTTP特性。你可以在在web service 中使用HTTP实现和和SOAP或者XML-RPC等类似的逻辑，而不是采用标准的SOAP或者XML-RPC。如果你打算用错误的方式使用HTTP，那还不如使用标准方式进行！大多数类似这种问题的讨论都是因为人们滥用了HTTP。
不要过度使用POST。POST在某些场合相对其他HTTP请求看起来“更加灵活”。相对于其他的HTTP方法POST的定义相对灵活，并且他支持同步收发信息。因此很多人认为采用POST可以解决所有问题。在你的第一个REST WEB Service，我建议你只有在创建一个新的URI资源的时候才使用POST。设想下POST仅仅意味着“在当前的URI里创建一个新的URI”。有的情形下，你有可能在对于资源的某个操作是否需要使用POST的时候犯迷糊。据过往的设计经验，请仔细想想是不是用其他的HTTP请求就不能解决问题，如：GET, DELETE或者PUT，另外是否可以分拆到一套组合的方法里。
不要依赖URI内在的结构定义语义。有些人认为REST设计是由一对URI资源组成的。“我把采购订单放入/purchases，给所有的订单一个编号，像/purchases/12132，客户记录将在/customers...“ 当你在设计阶段，通过电子白板和即时通讯沟通的时候，这是一个好的沟通方式，但是这不是最终的服务接口定义。根据web设计的原则，大部分URI在大部分时候对于客户端软件是不透明的。换句话说，你公布的API不可以依赖URI的结构定义语义。你需要定义个一个单独的XML文件列出服务中的所有组件。这些组件将有超链接指向别的组件。这样你就可以通过一个URI向人们展示你整个SERVICE，另外你还可以根据需要跨越服务器和域分发你的组件。我的经验是客户只有在使用查询字符串时才需要构造URI。这些查询字符串通过URI返回相对应的对象。
不要在URI里定义动作。这个原则是由上一条自然产生的。有一种对URI的滥用有着特别恶劣的危害，如，构造一条这样的查询字符串“someuri?action=delete”。首先，采用GET来做一个这样的动作是不安全的。其次，在"action URI" 和 "object" URI之间没有一个正式的关系。最后你的“action=” 协定变成了你的程序特有的东西。然而REST做的却是尽可能的使诸多的“程序协定”超越协议。
服务是不常用的资源。在REST设计里，一个“常备引用服务”并不是很有趣。在一个REST设计中，你需要有一批常备的资源，一个服务只是对这些资源的引用而已。
会话和REST是无关的（REST是无状态的--这样是不是更合适）。一个客户端没必要去去调用类似“login”或者“start a connection”这样的指令。HTTP本身就有完善的验证机制自动的检测每条信息是否验证通过。客户端程序只是来访问资源，不是服务本身。因此完全没有登录的必要！打个比方说你通过REST服务预定了一个航班。你并没有在创建一个新的会话连接到服务。相当于你请求“流程创建对象”帮你创建一个新的路程。你可以开始填写资料，然后在网络上的其他组件填写另外的资料。这里并没有会话，因此并没有在不同客户端迁移会话的问题。同样也没有类似的会话相关的问题出现在服务器（虽然它们是在集群上运行的）。
不要采用专有的对象标识。如果采用URI。URI是非常重要的，因为你可能在两天内对于同样的URI关联上不同的信息。为了能够简单的发布数据到web服务器，因此需要将发布数据和获取数据的URI分离。注意这个技巧只能用在可以分离的URI（HTTP URI）类型中，因此URN 或 UUID-based URIs比起HTTP URI并不是很合适。另外也可以使用RDF和其他类似的技巧，它们允许在URI中加入元数据，但是这些就不再受你控制了。如果你采用UUID或者其他类似的方式解析URI，就意味着你得到了URI的一般好处。你得到了标准的解析方式但是没有标准的分离资源的能力。如果你使用一个HTTP URI 那么你将获得另外一半好处，因为你可以通过标准的方式分离资源。
不要担心协议的独立性。针对适当的资源操作的语义只存在一个协议。如果将来发展出来了另外一个，只需要简单的保留相同设计，仅仅支持替换的协议接口而已。另外一个方面，人们通常所说的“协议独立”是放弃资源模型，因此也等于放弃了REST和WEB。

总体来说，始终需要牢记的是，REST关于如何通过URI展示资源的方案，不是一个通过消息结构提供的服务。

译自：

Common REST Mistakes

by Paul Prescod
http://www.prescod.net/rest/mistakes/

第一次翻译文章，不当之处欢迎指正。

另外文中的很多见解我也有理解模糊的地方，有问题请参考英文原版。