REST API 不得定义固定的资源名称或层次结构（客户端和服务器的明显耦合）。服务器必须可以自由控制自己的命名空间。相反，允许服务器通过在媒体类型和链接关系中定义这些指令来指导客户端如何构建适当的 URI，例如在 HTML 表单和 URI 模板中完成。
您如何为系统到系统接口执行此操作？假设客户想在http://my.server.org的服务器中创建一个订单，它应该如何知道创建一个订单应该使用 URL http://my.server.org/newOrder而不是http://my.server.org/nO或其他任何东西？
对于人机界面（即浏览器），我猜服务器会提供某种形式的链接（可能在一个form元素中），并且该链接周围的文本会告诉用户该页面上的哪些表单是正确的创建表单一个订单（应该创建一个用户或导航到某个搜索结果）
在客户端实现这一点的机制是什么？还有：它们是否真的被使用过，还是大多数人只是将 url 硬连线到客户端中？
您如何为系统到系统接口执行此操作？假设客户想在http://my.server.org的服务器中创建一个订单，它应该如何知道创建一个订单应该使用 URL http://my.server.org/newOrder而不是 http://my.server.org/nO或其他任何东西？
它不学习。机器客户端通常不能“学习”。至少现在还没有，我们还处于天网之前。你必须“教”他们。
但关键是你不教他们 URL。你教他们关系。
考虑一下，在 HTML...
<a rel="order" href="http://my.server.org/newOrder"/>
和
<a rel="order" href="http://my.server.org/nO"/>
您会注意到 rel 是相同的“order”，但 URL 不是。
在“完美”的世界中，您的系统将有一个入口点，例如http://my.server.org/，客户端可以从那里找到它需要了解的所有相关信息。
在实践中，许多系统都有几个“众所周知的”和定义的入口点，客户端可以从这些入口点开始，这只是一种权宜之计，因此客户端不必总是从系统的根目录开始。这些众所周知的入口点有来自提供商的隐含承诺，即这些 URL 不会很快改变。他们很长寿，服务器会很好地支持他们。
但是一旦通过入口点，您发现的任何 URL 背后都可能没有这样的承诺。URL 可以是一次性 URL。它可以被定向到不同的机器，例如，负载平衡。谁知道。但是作为服务的消费者，你并不关心 URL 是什么，你只关心关系。该关系告诉您要使用的 URL 的详细信息。
您的超媒体 API 的文档解释了如何将统一接口应用于您的客户端将遇到的每个 rel。客户也不能“直觉”，它必须被教导。
基本上，通过教客户端如何导航它将或可能在其处理的有效负载中找到的关系，就是客户端如何操作超媒体 API。有效负载包含指示路标的路标，但服务器指示这些路标的去向。
至于它的使用频率，在机器对机器的世界中，可能不是很多。大多数系统都不够大，因为 URL 发生了足够大的变化，而且客户端太少，以至于更改客户端并不是一个重大负担。所以大多数只是硬编码。
但是，最后，你只有坏客户。REST 系统对不良客户端无能为力。无论如何，它无法在运行时区分它们。
无论您如何发布 API（供机器使用），都可能进行重大更改。
将 API 封装在 UI（例如 HTML 表单）后面时，您可以自由更改 URI 而不会破坏用户，但这是因为用户正在使用您提供的抽象。在不更改表单的情况下更改 URL 架构，您仍然会破坏客户端。
避免破坏机器客户端的几种方法（基本上，支持向后兼容）：
我们通过以下方式非常成功地处理了它：在应用程序的根 URL 处公开一个 WADL 文件，描述媒体类型以及在哪里可以找到其中的链接及其语义。我知道这（WADL）是 REST 社区中的一些人认为的关键，但我总是对 WADL 的 URL 焦点感到害怕。除了所有的宗教辩论之外，我们还喜欢有一种明确的记录陈述的方式。有一种方法可以绕过 WADL 的 URL 焦点，而是指出可以在表示中找到链接的位置，然后将其记录下来。有关该方法的详细信息，请参阅该博客文章（目前由于维护而关闭，因此您可能希望在Google 缓存中查看它）。
这导致客户端只知道一个 URL，因为他可以了解它访问 WADL，然后只了解表示和在哪里找到链接、什么 HTTP 方法在调用时需要什么参数等等在。