陈材华

@afc163 已改

api接口应该有2重状态，http status是连接本身的状态，200表示请求接收成功，没有明显的异常，但并不能表示业务代码执行完全成功，没有异常。

@JasinYip 503,101等http状态是有意义的，但对于前端没有太大的意义。前端要的是数据的正确，而不是接口状态的正确。 同样的500状态，可以有很多的触发情况 1. api服务器本身的500 2. 接口api缺少参数 3. api nginx等同类服务的500 4. api获取数据异常 5....各种其他的错误 如果服务端只告诉前端是500状态，前端怎么来区分当前的状态是什么情况？更何况http只有状态码，没有对前端有效的错误信息,难道要前端去分析http协议？分析500状态服务端返回的一堆对于前端无意义的数据？

@iamcc 你估计是写接口的吧，不是用接口的，接口随便写，不想被约束？

考虑一下大家最容易碰到的环境： 假如你的系统有100个API，提供给app或者前端开发使用（100个接口的应用应该还是比较小的系统吧），然后每个接口都非常的有个性，开发API的服务端人员是轻松了，他可以非常个性，想怎么写就怎么写； 但作为APP和前端的感受呢，有没有想过？AJAX数据请求会有100种写法。如何来管理这些请求？如何来做数据缓存？如何做前端优化？ 最严重的是，如何来维护这套系统？

有300个接口，1000个接口又是什么情况？

@iamcc 我是在抄袭文章？你是指这篇吗？http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api? 我的想法和他有很大交集？我只是站在前端的立场，希望后端api服务能提供restful服务，很抱歉，有太多的后端程序员不知道restful是什么，不知道jsonp是什么？

@JasinYip 看清楚了，再来BB，这是在写restful 规范吗？我只是引用了阮一峰的restful规范，主题不是restful，身为中国人，看不懂中文才是最可怕的。这篇文章不是为你这样的服务的，你也看不懂这篇文章在说的东西。

写这个完整版处于几点考虑： 1. 补全之前文章的内容 #126 文章描述的不够清晰，不够全面，那是应急写的 2. 规范前后端的api开发流程和规程 3. 方便前后端开发的配合和前端的调试，加速功能的实现 4. 优化移动端的开发模式 5. 优化移动端开发的数据本地存储提供有效的保障 6. 这个完整版会成为公司的一个执行标准，当然之后也会有更多的完善

另外，非restful接口，那是我在2013年就开始实施的方案，我不知道之前是否有人有提出过之类的观点和文章，如果有，那么请告之，我增加文章的引用说明。