Eric
Eric
@TakWolf 好坏可以讨论的。只要是更加好的建议，就可以吸收。
@TakWolf action当然不是冗余字段，通过 action，我可以不必使用POST/GET这类没有明确语义的HTTP方法。
http里面没有login这样的方法。 并且REST完全不依赖于COOKIE，而EGG设计即支持COOKIE，也支持TOKEN
@TakWolf 错误格式当然可以私有定义，但是定义基本的错误格式有助有规范一个API，同样可以更好的促进交流。定制好API的格式，不表示限制了API的私有化。但是同样可以促进公共错误的形成，而不必浪费时间自己各自定义一套，并且每一套都是不完善的。
@TakWolf 还有规范只是限制了字段，并没有限制自由定义错误。 同时errorable定义了常用的错误供选择使用，不是一件很方便的事情吗？ 感觉槽吐的深度不是很够啊。
@TakWolf 关于格式定死的好处是。 1. 提交json或者其它数据导致HTTP解析增加不必要的负担。 2. 过于灵活的理念，无法形成通用的API架构。（到目前为止还没有一个所谓的RESTful API规范，因为无法定义） 3. 通过API来表示资源的理念并不实用，对于服务器的解析要求过高，同时提高了服务器的安全风险。 4. 蛋蛋API不支持将API当成是媒体资源。蛋蛋API要求媒体资源完全独立于API。 5. 蛋蛋API只关注业务资源，即用户，商家，商品，等抽象概念的业务。而不是PDF，DOC等文件资源。
主要关注的是业务。 资源交由专门的资源接口处理。 特别是现在是云计算时间，静态资源就全部独立出来即可。 而这些静态资源可以考虑使用RESTful APIs，但是本质上也没有必要。 目标是其他人或者公司只要按这个标准去实现就可以了。 所以你写过一次的API后，可以与很多公司的API通过。 从而更好的复用代码与复用API。 而资源下载的功能一样可以复用。 创建用户建立的方式： /users POST action=create&username=xxx&password=xxx 对于变更来讲，更加建立采用post的方式。
这也是我要讨论API设计原则，以及如何看待RESTful APIs，然后着手制定EGG API的原因。 也欢迎提更多的建设性意见或者参与一起改进。
RESTful的架构未必就是最优的。 但是不管是什么新技术，引入国内从来没有人质疑过。 这不是一个好的现象。 /account/register /user/register 这样去定义并没有什么不妥，但是 POST /user action=register 或许更加符合HTTP。 但是应用为什么一定要符合HTTP协议呢？ 所以蛋蛋API会基于一些RESTful APIs的优点，去考查API的设计。 也欢迎提供意见。
@TakWolf 基于HTTP的错误描述性太差了，并且可扩展性更差。 SOAP基于XML，并且也很复杂，而目前来看REST也一点也不简单。 egg api目前还处于最早期的状态，所以肯定不会非常完善，但是我相信可以做的比REST更加实用。