我是一个人么，还有人觉得 RESTful 是糟糕的设计么。

[jybox]

我主要写后端代码，以前写 PHP, 现在写 Node.js. 刚听说 RESTful 的时候，觉得很高端大气上档次，很理想很美好。但在后来的实践中发现 RESTful 很大程度上拖慢了后端的开发速度，而对前端(AngularJS)的开发速度改善也很有限。

RESTful 希望将所有请求都包装成对资源的新增，读取，修改，以对应不同的 HTTP 动词，但是并非所有请求都可以归到前面几类，既然无法将所有请求都 RESTful 化，甚至无法将大部分的请求 RESTful 化，那么意义就很有限了，会导致花费大量时间斟酌 API 应该如何设计。

RESTful 将一部分参数放到了 URL 里，还有一部分参数在 Header 里，从 URL 和 Header 里分离参数，虽然有库的辅助，但是我觉得很麻烦。

RESTful 通过 Status Code 来表示结果状态，但是通常的情况下，结果只有成功和出错两种情况，出错的情况分很多种，原因都很复杂，即使有 Status Code 依然需要有一个字符串来描述错误详情，所以 Status Code 在这里就显得很多余了。

所以我现在开始坚定地黑 RESTful, 我认为「传统」的 API 设计才是最可行的，即：

* URL 是一个动词，其中不包含参数。
* 没有副作用的请求可以用 GET, 其余必须 POST
* POST 时用正文传递参数，GET 时用 Query String 传递参数
* Status Code 为 200 或 400, 后者会返回一个字符串形式的错误代号。

[Wuvist]

你不是一个人，我就很讨厌restful，万物皆resource就跟OOP万物皆对象一样。

RPC才是王道。

[learnshare]

可以结贴了，某些争议多余且肤浅。程序跑得欢就行，老板只看效果，不管具体实现。

[RIcter]

@Wuvist 你不是一个人...看到这句我笑喷了...
cc @jybox

[heganj]

试试SOAP就知道了

[jybox]

@mfaner
@heganj
WebDAV 和 SOAP 都是访问资源的协议啊，但是后端 API 实际上更像是 RPC

[chemzqm]

REST只是一套规范，它确实是让一些原本简单的事变得复杂了（其实不过是因为需要思考的多了，开发变慢了），你也完全可以不遵守，但是对于相对复杂的应用而言，它能让接口变得更加简洁，易于理解，同时保证一定程度的扩展性，使用一套规范无论是你自己将来还是新来的维护者都可以更容易的理解你的应用，至于你说的多种状态码完全可以根据你的需求通过中间件统一处理。
RPC对于单纯的开发来说确实更便捷，但是将来的理解和扩展就没那么容易了。

[sharpnk]

"Status Code 为 200 或 400, 后者会返回一个字符串形式的错误代号。"

然后你再在前端去解析回复字符串？ 实在是无法想象怎么会有人觉得这是个好主意。

如果每个Web API都能严守http规范来回复请求，这个世界会美好太多。

[mengzhuo]

正好可以吐槽一下Django rest framework,就是基于Django Model的新框架.
太他妈的方便了

[reorx]

HTTP 协议本身是很语义化的东西，RESTful 的目的是希望 HTTP 中语义化的成分能和你的接口设计相对应，说白了是让协议和应用相统一的规范。

但是协议所能表达的语义有限，不可能要求所有的事情都用 GET POST PUT DELETE 等表达，因此我现在的做法是将可以归入 RESTful 范畴的接口用 RESTful 的规范设计，不好归入的在 URL 中加入动词，用 POST 方法做请求。拿 V2EX 的主题顶踩为例，我会设计为 POST /topics/:id/voteup，POST /topics/:id/votedown，并在代码或文档中注明这个接口和其他 RESTful 接口的区别。

至于 Status Code 的使用，个人认为统一的意义大于规范性，如果你是从头开始主导的项目，当然可以用 Status Code 的不同区分返回的错误，如 @cloudzhou 所列出的那些。但是如果半途加入一个项目，这个项目之前已经是使用 200 返回所有请求，重新设计 Status Code 的成本太高，甚至可能对其他业务造成影响，这时可以考虑在返回数据中描述返回结果的状态。RESTful 也并不是就限制死了你对它的使用，使用方式见仁见智。吸取其中适合自己的成分，作出适合团队协作，提升开发效率，清晰而稳健的接口设计，就是最好的。

[reorx]

P.S. 上面提到的“在返回数据中描述返回结果的状态”，推荐一个叫 JSend 的简单规范: http://labs.omniti.com/labs/jsend

[chilledheart]

@mengzhuo 你是说 django-rest-framework.org 这个框架嚒？先前一两周还拜读过这个框架作者的一篇文章（http://www.slideshare.net/silota/building-restful-apis），窝认为一些restful api有趣的概念比如 security(auth),base URL, serialization, timestamps, versioning, caching, gzip, logging 等等(http://www.django-rest-framework.org/api-guide/serializers)，对设计整个API的模式大有裨益。

相关还有这一篇文章 http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api。

窝非常在意为什么Python就可以有这么好的框架，然后node.js 社区就好像没有（restify？），真的是很羡慕。

[undeadking]

RPC是企业内部应用开发的产物,如果给移动APP用这种思路设计API,根本就不好用.

RESTful的URL规范能让运维去直接档掉拖垮服务器的请求,压根不用程序员出马.楼主这种是压根没搞懂RESTful是啥,急于生搬硬套才折腾到自己,一种风格而已,不是要你全部严格遵循的.难道你现在设计数据库还要对着课本的一二三范式去严格遵循吗?

[qibinghua]

喜欢啥就用啥,方便简单就好啊.. 至于安全什么的,在hacker眼里.规范那算个事吗

[picasso250]

@cloudzhou
201 有一个新的资源已经依据请求的需要而建立

你把201理解成409类似的了

话说. 我是部分同意楼主的. URL restful, 状态码统一在body里返回(而且要用0表示正常), 才是最省口水的. 大部分程序员只认识http code 中的 200 和 404 ! 我没有在开玩笑.

[cloudzhou]

@picasso250 是的，我记错了，你这个建议在一些情况下我也同意，在现实中遇到一些问题，比如把 rest http api 放在页面编程的时候遇到的。

[un]

@Wuvist 本来就是在请求资源 “皆resource” 不对么？

[Wuvist]

@un 比方说，user login , change password，这是在『请求资源』嘛？

[jybox]

@Wuvist 我是楼主，经过一年多的实践，我的观点是有一些变化的，现在我觉得，Restful 是一个简单的、通用的设计，而在设计具体的 API 的时候，可以代入一些 Restful 的风格，这样方便他人理解，也方便配合一些现成的工具，但不必死守 Restful, 具体情况具体分析。
关于 user login 和 change password, 我觉得其实也可以略牵强地抽象为对资源的操作。user login 可以看作是在创建一个 token, 而 change password 则是在修改用户的密码这样资源。

[Wuvist]

@jybox http://www.zhihu.com/question/28570307/answer/47876255 供参考