后台服务之RESTful API

程序员说的 REST 并不是我们理解的英语单词“REST”,它是 Representational State Transfer的缩写,意为“表现层状态转化”。REST是一种定义API的风格。
我们在之前的章节曾经介绍过API,它是一些能力的集合。比如程序员老王写了一个“把大象装进冰箱”的API,如果程序员小明在实现产品经理的需求时,也需要把大象装进冰箱,他就可以直接调用程序员老王提供的API,不用再费时费力做一遍“把大象装冰箱”的逻辑。API 有很多种,如果我们的项目里用到别人提供的 SDK,就要用SDK里定义好的API。放到REST这里,则指的是网站的后台给前端提供的API到底是一种什么样的风格。
我们举个例子。做后台开发的程序员老王实现了一套好友管理系统,可以为当前用户添加、删除好友,也可以查询用户的所有好友。他写了一套API,包含add_friends、delete_friends和get_friends三个功能。前端人员想要调用他的API,只需要访问不同的URL。比如想要添加好友,可以用http://api.laowang.com/add_friends.php这个URL,其他API依此类推。
假如用户单击了查看好友列表的按钮,前端就会访问http://api.laowang.com/get_friends.php,后台收到之后,知道前端想调用“查询好友”的 API,就会把所有好友的数据返回给前端。这是一种“简单粗暴”的 API 设计风格。后台针对添加、删除和查询好友设计了三个URL,然后根据前端访问的URL来判断其目的。人们一开始发明HTTP、使用URL的时候就想到了根据URL来区分API,这么做的后果自然是URL越来越长,到后面前端也不知道自己在用什么URL了。直到有一天,有人提出了REST的设计风格,才使得整个API的设计充满了美感。
REST 风格是如何满足老王的需求的呢?首先,它规定 URL 只能表示资源。也就是说,REST 是面向资源的,服务器上有什么东西,都会通过 URL 暴露出来。在这个例子里,服务器上有一个好友列表,那它对应的 URL 就是 http://api.laowang.com/friends。无论是添加、删除还是查询,只要是针对好友列表的操作,都只能用这个URL。
那么,后台如何区分前端到底是想添加好友、删除好友还是查询好友?很简单,交给HTTP去做。HTTP原生支持4个动词,分别是GET、POST、PUT和DELETE(如表5-5所示)。平时我们浏览网页的时候,浏览器会用GET动词去服务器上拉取资源,这个操作也可以理解为查询。当我们要登录某个网站的时候,我们填写的账号、密码之类的信息会通过POST请求上传到服务器。PUT和DELETE很少有用武之地。

针对好友列表的一系列操作,可以分别用HTTP的4个动词发起请求。比如删除一个好友,就是用DELETE访问http://api.laowang.com/friends。尽管服务器收到请求的URL都相同,但是它可以根据请求来的动词区分前端到底想调用哪个API,这便是REST的精髓所在。它把访问服务器的过程看作操作数据库。数据库里的资源可以根据表名来定位,服务器上的资源也可以用URL定位。我们对数据库的操作主要是CRUD(增查改删),利用REST,我们也可以对后台资源进行CRUD。

摘自《给产品经理讲技术》

推荐阅读更多精彩内容