程序员说的 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。
摘自《给产品经理讲技术》
