答案很简单，罗伊·菲尔丁写了一篇论文。]1在那篇论文中，他定义了REST原则。如果应用程序满足所有这些原则，那么这就是REST应用程序。

之所以创建RESTful一词，是因为ppl通过将其非REST应用程序称为REST而耗尽了REST一词。此后，RESTful一术语也耗尽了。现在我们讨论的是Web API和超媒体API，因为大多数所谓的REST应用程序都没有实现统一接口约束的HATEOAS部分。

REST约束如下：

客户端-服务器体系结构因此，它不适用于例如PUB/SUB套接字，而是基于REQ/REP。无状态通信因此，服务器不维护客户端的状态。这意味着您不能使用服务器侧会话存储，并且必须对每个请求进行身份验证。您的客户端可能通过加密连接发送基本身份验证标头。（对于大型应用程序，很难维护许多会话。）如果可以，请使用缓存因此，您不必一次又一次地满足相同的请求。作为客户机和服务器之间通用契约的统一接口客户端和服务器之间的契约不由服务器维护。换句话说，客户端必须与服务的实现分离。您可以通过使用标准解决方案来达到这种状态，例如用于标识资源的IRI（URI）标准、用于交换消息的HTTP标准、用于描述消息体序列化格式的标准MIME类型、用于描述邮件体不同部分语义的元数据（可能是RDF vocabs、微格式等）。为了将IRI结构与客户端分离，必须以超媒体格式（HTML、JSON-LD、HAL等）向客户端发送超链接。因此，客户端可以使用分配给超链接的元数据（可能是链接关系、RDF vocabs），通过适当的状态转换来导航应用程序的状态机，以实现其当前目标。例如，当客户想要向网络商店发送订单时，必须检查网络商店发送的响应中的超链接。通过检查链接，可以找到http://schema.org/OrderAction.客户机知道schema.org vocab，因此它知道通过激活这个超链接，它将发送订单。因此它激活超链接并发送POSThttps://example.com/api/v1/order以恰当的方式传递信息。之后，服务处理消息并以具有正确HTTP状态标头的结果进行响应，例如201-由成功创建。为了用详细的元数据注释消息，标准解决方案使用RDF格式，例如JSON-LD和REST vocab，例如Hydra和领域特定vocab（如schema.org或任何其他链接数据vocab），如果需要，还可以使用定制的应用程序特定vocab。现在这并不容易，这就是为什么大多数应用程序使用HAL和其他简单格式，这些格式通常只提供REST vocab，但不提供链接数据支持。构建分层系统以提高可扩展性REST系统由层次结构层组成。每一层包含使用下一层组件的服务的组件。因此，您可以轻松添加新的图层和组件。例如，有一个包含客户端的客户端层，在该层之下有一个服务层，该服务层包含单个服务。现在，您可以在它们之间添加客户端缓存。之后，您可以添加另一个服务实例和负载平衡器等…客户端代码和服务代码不会更改。扩展客户端功能的按需代码此约束是可选的。例如，您可以向客户端发送特定媒体类型的解析器，等等…为了做到这一点，您可能需要客户端中的标准插件加载器系统，或者您的客户端将耦合到插件加载器解决方案。

REST约束导致了一个高度可扩展的系统，其中客户端与服务的实现分离。因此，客户端可以是可重用的，就像web上的浏览器一样。客户机和服务共享相同的标准和语音，因此尽管客户机不知道服务的实现细节，但它们可以相互理解。这使得创建能够找到并利用REST服务实现其目标的自动化客户端成为可能。从长远来看，这些客户端可以像人类一样相互通信，在任务上相互信任。如果我们向这些客户端添加学习模式，那么结果将是一个或多个使用机器网络的人工智能，而不是一个服务器园区。因此，伯纳斯-李的梦想终于实现了：语义网络和人工智能将成为现实。因此，到2030年，我们最终被天网终止。在此之前…；-）

如果我没有直接回答这个问题，我很抱歉，但通过更详细的例子更容易理解这一切。由于所有的抽象和术语，字段化并不容易理解。

这里有一个很好的例子：

解释REST和超文本：垃圾邮件清理机器人Spam-E

更棒的是，这里有一个简单的例子（powerpoint更全面，但你可以在html版本中获得大部分内容）：

http://www.xfront.com/REST.ppt或http://www.xfront.com/REST.html

看完这些例子后，我明白了Ken为什么说REST是超文本驱动的。但我实际上并不确定他是对的，因为/user/123是指向资源的URI，我不清楚它是否是非RESTful的，因为客户端知道它是“带外”的

xfront文档解释了REST和SOAP之间的区别，这也非常有用。当Fielding说：“这是RPC。它尖叫RPC。”时，很明显RPC不是RESTful的，所以了解这一点的确切原因很有用。（SOAP是RPC的一种类型。）

Edit

阅读这里的自述文件，我希望你真的能得到REST。

https://github.com/lukepuplett/surfdude-csharp/blob/master/README.md

--

这些给出链接资源示例的答案很好，但只占一半。

所以，想象你正在设计一个网站。你写一个故事，

我希望能够通过邮政编码搜索地址，以便选择发货地址

然后，您将构建网站，让用户踏上旅程，并尝试在工作流中将页面链接在一起。

一个网站设计让他们进行地址查找，然后让他们将地址复制到剪贴板，然后返回到发货地址表单，这是不太有用的。

REST API使用我们在web上认为理所当然的模式进行机器-机器交互。

对邮政编码功能的搜索不应该是base/addresss/{postcode}，并且会返回一个集合，即使每个地址都链接到一个完整的地址和一些编辑链接，因为这是一个死胡同；API使用者需要猜测如何使用该地址。

相反，该功能的动机应内置于其使用的流程中，以便旅程在开始时结束：

1 GET /orders/123/shipping

  200 OK { Current shipping details + link to parent + link to address picker }

2  -> GET /orders/123/shipping/addresspicker

      200 OK { Link and form for searching for a postcode }

3   -> GET /orders/123/shipping/addresspicker?postcode=tn11tl

       200 OK { List of addresses each with link to pick it }

4    -> POST /orders/123/shipping/addresspicker?postcode=tn11tl&pickNo=3

        200 OK { Current shipping details + link to parent + link to address picker }

这是一次用户旅程，最后您可以看到流量对订单的影响。

HTTP请求/响应严格来说不是REST的一部分，但我认为没有人见过非HTTP REST应用程序。

现在这些URL可以是任何一组字符，它们只是标识符，我把它们做得很漂亮，因为它们对人们来说很有意义。机器将使用rel来计算它们做什么，而不依赖于可读的href。

这是一种编程，您的系统架构符合Roy Fielding在论文中提出的REST风格。由于这是描述网络的架构风格（或多或少），所以很多人都对它感兴趣。

另外一个答案是：没有。除非你是作为学术研究软件架构或设计web服务，否则真的没有理由听过这个词。

为了在这里贡献一些新的东西，我想分享我文章中的链接，即通过一种实用和客观的方法将REST概念化。

我将介绍以下主要概念：

HATEOAS-超媒体作为应用程序状态的引擎，资源和表示，可寻址性，REST中的幂等性，Richardson的REST成熟度模型。媒体类型API版本控制

我还创建了一个GitHub项目，您可以使用docker轻松运行，它涵盖了我在本文中介绍的内容。

https://itnext.io/how-to-build-a-restful-api-a-deep-dive-into-rest-apis-215188f80854

REST==HTTP类比是不正确的，除非你不强调它“必须”是HATEOAS驱动的。

罗伊自己在这里清除了它。

输入REST API时，除了初始URI（书签）和适用于预期受众的一组标准化媒体类型（即，预期任何可能使用该API的客户端都能理解）之外，不应有任何先验知识。从那时起，所有应用程序状态转换都必须由客户端选择服务器提供的选择来驱动，这些选择出现在接收的表示中，或者由用户对这些表示的操作来暗示。转换可以由客户端对媒体类型和资源通信机制的知识来确定（或限制），这两者都可以动态地改进（例如，按需编码）。

[这里的失败意味着带外信息正在驱动交互，而不是超文本。]