——evilrescuer翻译自Ruben Verborgh写的《What is a REST API?》
REST是不同于其他系统的一种描述网页如何架构的方法。
Web是一种可以轻易地通过你的浏览器访问的，位于因特网最上层的信息网络。在许多方面，它有着和其他计算机系统不同的架构。
REST是一种用来设计系统（如Web）的架构风格。REST最典型的特征就是统一接口的四个约束。REST接口遵循这四个规范。
约束1：提供通过资源的访问
在典型的计算机系统中，客户端和服务器交换命令：做这个，做那个。假设我们想用非REST的方式模拟一个to-do列表，用技术语言，这可能长这样：
非REST
/changeTodoList.php?item=35&action=changeTitle&title=new_title
注意，它的的确确是一条指令：改变某个东西。
但“changeTodoList”不是一个东西，不是一个资源。
在REST架构风格里，服务器仅仅提供资源。资源是概念上客户端和服务器通讯的东西。
REST
/todolists/7/items/35/
上面这串东西不是一个命令，而是一个资源、一个东西的地址。你可以使用这个地址，用标准的方法去操纵to-do列表，而不是用特定接口的命令。
约束2：通过陈述表现资源
一个资源是我们能用不同的格式描述的东西。例如，人们可能想理解由浏览器转换成的可读布局的HTML版本。但有时Web上的接口是提供给机器使用的，它们需要一个不同的格式，如JSON。
通过非REST的方式，不同的格式具有不同的地址：
非REST
浏览器:/showTodoList.php?format=html
应用:/showTodoList.php?format=json
那么问题来了。这两个使用不同格式的系统彼此间无法通讯，因为它们在同一个东西上用不同的地址。
在REST系统中，地址与东西一致，而非格式，所以所有的系统在同一个东西上用同一个地址。那它们怎么获取不同格式的这个东西呢？它们明确地提出请求！
REST
浏览器:“我想要 /todolists/7/, 请给我 HTML。”
应用:“我想要 /todolists/7/, 请给我 JSON。”
使上面的方案可行的技术被称为内容协商。
约束3：交换自描述信息
在REST系统中，我们可以在不知道之前的信息时，单独解释任何一条信息。
想象一下下面的会话：
非REST
1./search-results?q=todo
2./search-results?page=2
3./search-results?page=3
第一个请求获取“todo”的查询结果；第二个请求获取第二页的查询结果；现在想象一下，你只看到了第二条请求，你怎么知道服务器接下来要做什么呢？
在REST中，每条信息都自力更生：
REST
1./search-results?q=to-do
2./search-results?q=todo&page=2
3./search-results?q=todo&page=3
注意每条请求是如何通过自身来解读的。
另一方面，REST客户端和服务器只采用描述里定义的标准操作。对Web来说，这个描述就是HTTP。
约束4：通过链接连接资源
你怎么导航到一个你从没有见过的网页？你使用链接！
当你访问一个新页面时，你不需要每次手动地编辑浏览器的地址栏。
在机器接口中，却并不尽然。假设一个应用请求to-do列表。它可能接收如下的描述：
非REST
/todolists/7/
{
"name":"My to-dos",
"items":[35,36]
}
现在你要如何获取这个列表中的各个项呢？
问得好！我们需要读一下相关的文件。
在REST中，资源彼此间通过超级链接连接在一起：
REST
/todolists/7/
{
"name":"My to-dos",
"items":["/todolists/7/items/35/","/todolists/7/items/36/"]
}
注意你是如何不通过手动的方式知道如何取得列表中的各个项的。其实，你只需要跟随着链接就好了。
遵循这些约束的接口就是REST接口
在你的接口里，遵循这四条约束，你就拥有了一个REST接口
不幸的是，许多自称是“REST”的接口，实际上只是其他的东西（“HTTP接口”），因为它们并不完全遵循所有这些约束。约束2和约束4常常被违反，但也很少见到违反约束1的。对这些开发者来说，“REST”简单地意味着“我们没有XML信息”。
这也是为什么遵循所有这四个约束的REST接口，如今常常被称为“超媒体接口”，这点与第四个约束有关。
