REST API不能定义固定 资源名称或层次结构（ 客户与客户的明显耦合 服务器）。服务器必须具有自由 控制自己的命名空间。 相反，允许服务器指示 客户如何建设 适当的URI，例如在 HTML表单和URI模板 在其中定义那些指令 媒体类型和链接关系。
如何为系统到系统界面执行此操作？假设客户想在http://my.server.org在服务器中创建订单。如何知道创建订单时应该使用网址http://my.server.org/newOrder而不是http://my.server.org/nO或其他任何内容？
对于人机界面（即浏览器），我猜服务器会提供某种形式的链接（可能在form元素中），并且该链接中的文本将告诉用户哪些表单在该页面是创建订单的正确页面（应该创建用户或导航到某些搜索结果）
在客户端实现此功能有哪些机制？而且：他们实际使用过，还是大多数人只是将网址硬连接到客户端？
答案 0 :(得分：6)
你是怎么做到的 系统到系统接口？说吧 客户想要在中创建订单 服务器在http://my.server.org怎么样 它应该学习创造 它应该使用网址的订单 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的详细信息。
超媒体API的文档说明了如何将统一界面应用于客户端将遇到的每个rel。客户也不能“直觉”这一点，必须要教它。
基本上，通过教导客户端如何导航它将在或将在有效负载中找到的关系，它处理的是客户端如何操纵超媒体API。有效负载包含标志信息以显示方式，但服务器指示这些标志信息的去向。
至于它的使用频率，在机器到机器世界中，可能不是很多。大多数系统都不够大，其中URL变得足够重要，客户端很少，更改客户端不是一个重要的负担。所以大多数只是硬代码。
然而，最后，你只是有坏客户。 REST系统无法对坏客户端做任何事情。无论如何，它无法在运行时区分它们。
答案 1 :(得分：2)
无论您如何发布API（由机器使用），都可以进行重大更改。
将API包装在UI（例如HTML表单）后面时，您可以自由更改URI而不会破坏用户，但这是因为用户正在使用您提供的抽象。更改URL架构而不更改您的表单，您仍然会破坏客户端。
避免破坏机器客户端的几种方法（基本上，支持向后兼容性）：
答案 2 :(得分：1)
我们非常成功地通过以下方式接近它：在应用程序的根URL上公开WADL文件，描述媒体类型以及在其中查找链接的位置及其语义。我知道这个（WADL）是一些在REST社区中被一些人认为很关键的东西，但我总是觉得只有WADL的URL焦点才会感到害怕。除了所有的宗教辩论之外，我们喜欢有一种明确的记录表达方式。有一种方法可以绕过WADL的URL焦点，而是指出可以在表示中找到链接的位置，然后记录它。请参阅that blog post（由于维护目前已关闭，因此您可能希望在Google cache中查看此信息）以获取有关该方法的详细信息。
这导致客户端只知道一个URL，因为他可以找到它访问WADL，从那时起只需了解表示和在哪里找到链接，什么HTTP方法需要什么参数被调用等等。