我主要写后端代码，以前写 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, 后者会返回一个字符串形式的错误代号。
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, 后者会返回一个字符串形式的错误代号。
4
Select Language