引子
Restful API 是现在比较常见的HTTP API设计方案了。不管是不是真的理解,很多项目组都开始运用restful思想设计API。前几天部门领导莅临指导,更是反复强调要 restful。姑且认为他也是经过深入研究的吧。
优点和缺点
restful 是一种简单的设计方案。它认为网站,或者说后台服务是对资源的管理,包括创建,更新,获取和删除。实际设计的时候,需要对资源进行合理的抽象。
restful 指导原则比较简单,一切皆是资源,api 就是对资源的管理。那么问题来了,如何有效的抽象这些资源? 比如, search 是非常常见的api,如何将它 restful 化呢?
基本原则
restful 认为一切皆是资源, API 应该是对资源的状态的转化。
url 路径中只应该包含资源标识符
比如,创建订单,非 restful API 可能是这样的:
/createPO
这个业务中,PO是一种资源,restful 风格的 API 应该应该是
/PO
那么,如何标志这个API 是创建 PO 呢?
利用 http method 定义资源状态转化
上面的例子,可以使用 POST 方法定义创建 PO。
POST /PO
restful 主张用http method来标志资源状态的转化,有下面四种:
POST 创建
PUT 更新
GET 获取
DELETE 删除
所以,对于PO,它的创建,更新,获取,删除,API如下
POST /PO
PUT /PO/:id
GET /PO/:id
DELETE /PO/:id
实践和思考
理论上来讲,restful 是让 API 的设计变得简单了。抽象资源+状态转化。实际中要注意的是对资源的抽象应该在较高的层次,即实际的业务层次。我见过很多的程序员都习惯从数据库的角度来抽象资源,比如,一个表就对应一个资源。这是没有意义的,这样的API只是变相的对数据表的抽象,而非对资源的转化。因为很多表的数据本来是不应该被 API 操作的,而且,业务实体也不会映射到单一的数据表。说到底,API的用户,不管是第三方,还是前台,它们关心的并不是数据表的细节,而是业务实体。
所以,实际上的 POST API,也许并不仅是创建一行数据,也许它也同时更新了某些数据,删除了某些数据,这些都可以依具体业务而定。创建资源并不等于在某个具体的表中插入数据,而是在高层次的业务实体上的创建。
上面的例子,其实实际业务一般不会这么简单,比如PO都会从属于某一个用户,所以API的结构会是下面这样,以 PUT 为例
PUT /user/:userid/PO/:poid
这里就引申出一个值得讨论的话题,如何设计从属关系?从业务实体上设计从属关系可能会遇到一些困难,比如,某些情况下,父资源的创建可能会依赖子资源的创建。我的建议是,如果开销不大的话,可以重新设计一下业务。比如,PO必须从属于一个user,那么业务上就规定必须先注册(创建user)或者登陆,才能下订单(创建PO)。
遇到困难的时候
有些时候会遇到一些设计上的困难,可能是由于对 restful 的认识不深,或者业务实在太奇葩。如果不牵涉什么商业机密的话,可以向社区或者论坛求助。
当项目进度非常紧张的时候,这个时候还是要以实现功能为先,避免被指责。:)
总结
技术的变革一般都是为了提高生产力的,restful的初衷也是。它提倡简单(理论上讲只要业务实体抽象的好就够了),纯粹(每个资源就四种操作)的 API 设计思想,需要使用者坚持信仰(坚持基本原则),适度灵活。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。