引子
Restful API 是现在比较常见的HTTP API设计方案了。不管是不是真的理解,很多项目组都开始运用restful思想设计API。前几天部门领导莅临指导,更是反复强调要 restful。姑且认为他也是经过深入研究的吧。
优点和缺点
restful 开辟了一种简单的设计方案。它把网站,或者说后台服务看做对资源的管理,比如 创建,更新,获取和删除。针对这四类方法设计 API,使得架构清晰,易于管理。而且,充分的利用 http method 定义管理方式,使得,api 更易于理解和使用。
restful 的缺点就是,学习成本其实很高。它的指导原则比较简单,一切皆是资源,api 就是对资源的管理。那么问题来了,如何有效的抽象这些资源? 比如, search 是非常常见的api,如果将它 restful 化?
基本原则
restful 认为一切皆是资源, API 应该是对资源的状态的转化。
url 路径中只应该包含资源标识符
比如,创建订单,非 restful API 可能是这样的:
/createPO
这个业务中,PO是一种资源,restful 化应该改造成
/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
这里就引申出一个值得讨论的话题,如何设计从属关系?从业务实体上设计从属关系可能会遇到一些困难,比如,某些情况下,父资源的创建可能会依赖子资源的创建。我的建议是,如果开销不大的话,可以重新设计一下业务。
遇到困难的时候
有些时候会遇到一些设计上的困难,可能是由于对 restful 的认识不深,或者业务实在太奇葩。如果不牵涉什么商业机密的话,可以向社区或者论坛求助。
当项目进度非常紧张的时候,一切还是以进度为先。restful很好但也不能包治百病,总是会有完全没法使用的情况,那就先实现功能吧。
总结
技术的变革一般都是为了提高生产力的,restful的初衷也是。它提倡简单(理论上讲只要业务实体抽象的好就够了),纯粹(每个资源就四种操作)的 API 设计思想,需要使用者坚持信仰(坚持基本原则),适度灵活。