关于RESTFul Api的一些讨论 about vig-api HOT 10 OPEN

@TakWolf 好坏可以讨论的。只要是更加好的建议，就可以吸收。

from vig-api.

@TakWolf action当然不是冗余字段，通过 action，我可以不必使用POST/GET这类没有明确语义的HTTP方法。

from vig-api.

http里面没有login这样的方法。
并且REST完全不依赖于COOKIE，而EGG设计即支持COOKIE，也支持TOKEN

from vig-api.

@TakWolf 错误格式当然可以私有定义，但是定义基本的错误格式有助有规范一个API，同样可以更好的促进交流。定制好API的格式，不表示限制了API的私有化。但是同样可以促进公共错误的形成，而不必浪费时间自己各自定义一套，并且每一套都是不完善的。

from vig-api.

@TakWolf 还有规范只是限制了字段，并没有限制自由定义错误。
同时errorable定义了常用的错误供选择使用，不是一件很方便的事情吗？

感觉槽吐的深度不是很够啊。

from vig-api.

@TakWolf 关于格式定死的好处是。

1. 提交json或者其它数据导致HTTP解析增加不必要的负担。
2. 过于灵活的理念，无法形成通用的API架构。（到目前为止还没有一个所谓的RESTful API规范，因为无法定义）
3. 通过API来表示资源的理念并不实用，对于服务器的解析要求过高，同时提高了服务器的安全风险。
4. 蛋蛋API不支持将API当成是媒体资源。蛋蛋API要求媒体资源完全独立于API。
5. 蛋蛋API只关注业务资源，即用户，商家，商品，等抽象概念的业务。而不是PDF，DOC等文件资源。

from vig-api.

主要关注的是业务。
资源交由专门的资源接口处理。

特别是现在是云计算时间，静态资源就全部独立出来即可。
而这些静态资源可以考虑使用RESTful APIs，但是本质上也没有必要。

目标是其他人或者公司只要按这个标准去实现就可以了。

所以你写过一次的API后，可以与很多公司的API通过。

从而更好的复用代码与复用API。

而资源下载的功能一样可以复用。

创建用户建立的方式：

/users
POST

action=create&username=xxx&password=xxx

对于变更来讲，更加建立采用post的方式。

from vig-api.

这也是我要讨论API设计原则，以及如何看待RESTful APIs，然后着手制定EGG API的原因。
也欢迎提更多的建设性意见或者参与一起改进。

from vig-api.

RESTful的架构未必就是最优的。
但是不管是什么新技术，引入国内从来没有人质疑过。
这不是一个好的现象。

/account/register
/user/register
这样去定义并没有什么不妥，但是
POST /user

action=register
或许更加符合HTTP。
但是应用为什么一定要符合HTTP协议呢？

所以蛋蛋API会基于一些RESTful APIs的优点，去考查API的设计。
也欢迎提供意见。

from vig-api.

@TakWolf 基于HTTP的错误描述性太差了，并且可扩展性更差。
SOAP基于XML，并且也很复杂，而目前来看REST也一点也不简单。

egg api目前还处于最早期的状态，所以肯定不会非常完善，但是我相信可以做的比REST更加实用。

from vig-api.