[评论] REST 的缺点

04 Mar 2011

REST 优点就不多说了,大家也看了很多,这儿说一下缺点。

1. 滥用 HTTP 返回码

REST 推崇使用 HTTP 返回码来区分返回结果, 但最大的问题在于 HTTP 的错误返回码 (4xx 系列为主) 不够多,而且订得很随意。比如用 API 创建一个用户,那么错误可能有

  • 调用格式错误(一般返回 400,405)
  • 授权错误(一般返回 403)
  • "运行期"错误
    • 用户名冲突
    • 用户名不合法
    • email 冲突
    • email 不合法
    • 。。。

对于运行期错误,各家的处理也大不相同,用 400, 409, 412 都有, 也有的是混用

这个对于客户端或SDK开发者来说, 带来了额外的痛苦, 因为他们要处理三个层次的错误, 一个是网络层次的,比如连接超时,无法连接, 接着是 HTTP 返回码层次的,对于某些返回码,还要进一步深入到实际返回的数据, 获得更详细的返回码。

此外, 404 也是一个让你困惑的返回码, 你拿到一个 404, 根本无从知道自己是 URL 写错了,还是对应的数据不存在。随着 hypermedia 的引入,这个问题更严重

相比之下 XML-RPC[1], JSON-RPC[2] 在返回码设计上则更统一,更方便处理。

[1]  http://www.xmlrpc.com/spec

[2]  http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal

2. 为了 REST 而轻易地引入新的实体/概念

一个经常被提起的例子是转帐, 为了让 REST 更加自然,经常会引入一个新概念来封装这个行为。但这有几个问题

  • REST 只是一个接口设计模式, 你是否愿意为了你的接口设计去污染你的领域设计?轻量级的东西你还可以保持一个干净的接口肮脏的实现,重量级的东西你是否还舍得?
  • 在使用面向对象方法设计时, 通常我们会给对象很多方法,如果过度使用这种方法,会导致概念数量大规模膨胀, 无端增加了复杂度

当然,一般情况下大家还是会去扩展概念的 member 方法而不是引入新的概念

3. 客户类型很多时认证层变重

如果我们的应用有几类客户(比如同时有商家,用户,银行,仲裁这几类客户), 以前做法经常是为每类用户开发一套 API, REST 推荐的做法反而是使用同一套 URL, 再用认证层来区分不同类型的用户。如果针对不同类型的用户有不同的处理, 那么要么增加一额外的路由层,要么就会使你业务逻辑层分支过多,很难维护。

4. Hypermedia 是过度设计还是超前设计

REST 引入 Hypermedia, 把原始的一个个的 API 变成了一个网络,但会带来如下的一些问题

  • 客户端设计更复杂, 比如我要调用一个接口, 我需要从 API 总入口开始,逐级请求,才能拿到这个接口的 URL
  • 客户端需要理解 rel 的含义, 引入 Hypermedia 之前, 客户端只需理解服务的 API 列表, 请求和返回的数据规格, 现在呢?需要理解 API 入口,  请求和返回的数据规格, 以及各个 rel 代表的具体含义
  • link 很晦涩, 拿到 link url 之后你也不能清晰地知道该如何处理,比如一个花店的返回数据里边有个 order 的 link, 那么我应该怎么 order 呢?该 GET 还是 POST? 传递的数据类型究竟是啥?客户端还是需要额外的知识才能使用这个接口,对于自动化的能力里大打折扣。

以上只是我的一些个人看法, 现在 REST 的实践还在快速发展中,我自己对 REST 的理解也在不停变化,如有错误,望不吝指正。

Tags: rest

Related Posts:

comments powered by Disqus
Copyright © 2017 LI Daobing, Powered by github:pages, Jekyll, bootstrap, Designed by quanquan
Fork me on GitHub