为RESTful（超媒体）API编写客户端

几天来，我一直在阅读“真正的”RESTful API，我想我已经接近探索它的意义了

但我偶然发现的一件事是，我甚至无法想象如何为“真正的”超媒体API编写客户端：

我读过的大多数例子都是关于浏览器和爬行器的，但这并不是特别有用：一个是人类引导的“智能”，另一个是愚蠢的“随机”。目前，我的印象是，你需要学习人工智能才能让客户工作

我不清楚的一件事是，客户机如何知道在任何给定链接上使用哪个动词？uri的“rel”类型中是否隐含了这一点？另一种选择（阅读）似乎是使用xhtml，并拥有一个可以解析和发布表单的客户端

链路发生变化的可能性有多大，但到链路的路由不会发生变化？ 在您看到的大多数示例中，路线和链接是相同的：

如果我想建立一个客户，让我从托尼的蛋糕店取回蛋糕清单：

http://tonis.com
{ link: { type : "cakes" ; uri : "http://tonis.com/cakes" } }

当Toni's成为Toni's Food Shop，链接变成

http://tonis.com/desserts/cakes

我们是否将初始

cakes

链接保留在根目录下，以实现反向兼容性？如果没有，我们如何为这个可怜的小特工做一个“重定向”，他被告知“去根上，找蛋糕”

---

我错过了什么？

好吧，我也不是REST专家，我最近读了很多相关的东西，所以我要写的不是我的经验或观点，而是我所读内容的总结，尤其是这本书

首先，您不能逃避客户机和服务器之间的一些初始协议，REST的目标是让他们在与他们相关的事情上达成最低限度的一致，并让各方自己关心自己的事情。例如，客户端不应该关心链接布局或数据如何存储在服务器上，服务器也不应该关心客户端的状态。他们事先（即在交互开始之前）达成一致的是上述书的作者所称的“域应用程序协议”（DAP）

关于DAP，重要的是它是有状态的，即使HTTP本身不是（因为任何客户机服务交互都有状态，至少有开始和结束）。这种状态可以用“客户下一步可以/可能/预期做什么”来描述：“我已经开始使用该服务，现在怎么办？好的，我可以搜索项目。搜索这个项目，下一步是什么？好的，我可以订购这个和那个……等等”

超媒体内容类型的定义是能够处理数据交换和交互状态。正如我已经提到的，状态是用可能的操作来描述的，正如REST中的“资源”一样，所有操作都是用可访问的资源来描述的。我想，您已经看到了首字母缩略词“HATEOAS”（作为应用程序状态引擎的超媒体），这就是它的明显含义

因此，为了与服务交互，客户机使用他们都能理解的超媒体格式，可以是标准的、自制的或混合的（例如基于XML/XHTML的）。除此之外，他们还必须共享协议，这很可能是HTTP，但由于标准中省略了一些细节，因此必须有一些使用习惯用法，如“使用POST创建资源并进行更新”。此外，此类协议将包括服务的入口点（同样，就可访问资源而言）

这三个方面完全定义了域协议。特别是，客户端在开始使用服务之前不应该知道任何内部链接，也不应该在交互完成后记住它们。因此，内部导航的任何更改，如将

/cakes

重命名为

/f5d96b5c

，都不会影响客户端只要它遵守了最初的协议并从前门进入商店。

@Benjol

您必须避免针对特定URI对客户端进行编程。当您描述链接时，主要的重要性是它的含义，而不是URI本身。您可以随时更改URI，但这不应破坏您的客户端

我会这样改变你的例子：

{"link": {
  "rel":   "collection http://relations.your-service.com/cakes",
  "href":  "http://tonis.com/cakes",
  "title": "List of cakes",
  "type":  "application/vnd.yourformat+json"
}}

如果有客户使用您的服务，则需要了解：

• 链接结构本身
• 链接关系（在本例中为“集合”，即RFC和 ”“那是你的域名 特定链接关系）

在这种情况下，客户端可以取消引用“href”属性指定的地址并显示蛋糕列表。稍后，如果更改蛋糕列表提供程序URI，客户端将继续工作，这意味着客户端仍然理解您的媒体类型的语义

附言

• 请参见已注册的链接关系属性：
• 网络链接RFC：

。