REST架构
你是如何理解上网这件事的？
打开浏览器，输入网址，展现在你面前的就是一个网站了。
你可以在网站里看视频、看博客、写文章、听音乐。
但凡写过点代码的人都知道，我们平时访问的网站，其实是HTML，它不过是一个文本，只是通过渲染，在你面前变成了多姿多彩的网站。
上网这件事，其实就是把在服务器上的文本、视频、音频等资源，转化一下形式，呈现在你面前而已。
我们访问的每一个网址，都对应服务器上的一个具体资源，比如你现在看到的这篇文章，不过就是一个HTML文本而已。
这就是REST架构（Representational State Transfer），阮一峰老师翻译叫【表现层状态转化】。
我们看到的网页实际上是一个文本，状态转化一下，呈现在你面前的就是一个好看的网页了。
你点击网页上的一个按钮，网页势必有所变化，或者是打开一个新链接，或者是请求一些新的数据。
这个互动的过程，其实就是你在对服务器上的资源进行操作。
本质就好像你对自己电脑上的文件操作一样。
不信你打开文件资源管理器，输入网址，一样的能访问百度。
浏览器，实质上也是个文件资源管理器，只不过我们通常用来访问远程的资源，不然你复制一个文件夹的路径在浏览器打开试试。
你会发现浏览器其实也可以当文件资源管理器来用。
你在本地写了一个静态HTML，预览的时候，看到浏览器的链接也是这个HTML文件在你硬盘上的路径。
对RESTful API的应用
文件资源管理器上，一个文件路径代表一个文件，那么浏览器上，一个链接也代表一个资源文件。
你会在你的电脑上用动词去命名一个文件或者文件夹吗？
因此，如果遵循RESTful API，我们编写url的时候，应该都是名词，而不包含动词。
比如我们在编写【新增一个用户信息】的接口的时候，写出来的url很容易是localhost:8080/user/addUser。
但其实写出来的应该是localhost:8008/users。
这也是很多人的设计误区。
这样一来有人就会问了，那我增删改查，要怎么区分这些操作呢？
这些动作，可以用POST、DELETE、PUT、GET来标识。
我们就是通过这四个动作，来实现对服务器上的资源进行操作的。
同样是对用户信息进行操作，我们编写出来的接口可以是这样的：
# 获取用户列表
GET localhost:8008/users
# 获取单个用户
GET localhost:8008/users/userid
# 新增用户
POST localhost:8008/users
# 删除指定用户
DELETE localhost:8008/users/userid
# 更新用户信息
PUT localhost:8008/users/userid
不用怕链接冲突，你换了个动作，就是个新的操作。
看了上面的链接，其实也可以明白，GET代表查询，POST代表新增，DELETE代表删除，PUT则代表更新。
在RESTful架构中，每个网址代表一种资源，所有网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。一般来说，数据库中的表都是同种记录的"集合"，所以API中的名词也应该使用复数。
这样一来，我们对于编写链接，就有了个比较好的规范。
说到这里，可能说了一堆废话，毕竟有人觉得，localhost:8080/user/addUser这种写法并不影响使用，并且对很多人来说简单明了，为什么还要遵循这种看起来没什么用的API呢？
《Don't make me think》是一本讲网站设计的书，这是一本很好的书。
里面是这么看待约束和设计的（当时觉得挺好的就摘抄下来了，不过因为时间久了，我也忘记这段话是原文摘抄还是自己编辑过了）：
RESTful API是个很好的设计原则，它约束我们只能用名词去命名url，动作只能用GET、PUT来实现，这看起来是没什么作用的规矩，但最起码，在我url多到不知道下一个url怎么写的时候，遵循这个原则，能让我更好更快地想到下一个url怎么写。
再进一步，写的url越来越多，就感觉对【上网其实是在操作服务器上的文件资源】这个本质认知更深。
一个好的设计，应该是能让我们在遵循这个设计原则的时候，不仅能提高效率，而且能让我们对事物有更好的认知。