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 的理解也在不停变化，如有错误，望不吝指正。
