这几天我一直在阅读“真正的”RESTful API，并且我think我快要明白它的意思了。
但我偶然发现的一件事是，我什至无法想象如何为“真正的”超媒体 API 编写客户端：
我读过的大多数例子都谈论浏览器和蜘蛛，但这并不是特别有帮助：一个是人类指导的“智能”，另一个是愚蠢的“随机”。就目前情况而言，我的印象是，你需要学习人工智能才能让客户工作。
我不清楚的一件事是客户如何知道在任何给定链接上使用哪个动词？这是否隐含在 uri 的“rel”类型中？另一种选择（阅读here）似乎正在使用 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 专家，我最近读了很多相关的东西，所以我要写的不是我的经验或观点，而是我所读内容的总结，尤其是休息实践 book.
首先，你无法逃避客户端和服务器之间的一些初始协议，REST 的目标是让他们就与他们双方相关的最少事情达成一致，并让每一方关心自己的事情他们自己。例如，客户端不应该关心链接布局或数据如何存储在服务器上，并且服务器不应该关心客户端的状态。他们事先（即在交互开始之前）达成一致的是上述书籍的作者所说的“域应用协议”（DAP）。
DAP 的重要之处在于它是有状态的，尽管 HTTP 本身不是有状态的（因为任何客户端服务交互都有状态，至少有开始和结束）。这种状态可以用“客户端下一步可以/可能/预计做什么”来描述：“我已经开始使用该服务，现在怎么办？好的，我可以搜索项目。搜索此项目，下一步是什么？好的，我可以订购这个那个……等等”
超媒体内容类型的定义是能够处理数据交换和交互状态。正如我已经提到的，状态是根据可能的操作来描述的，并且来自 REST 中的“资源”，所有操作都是根据可访问的资源来描述的。我想，您已经看到了缩写“HATEOAS（超媒体作为应用程序状态引擎），这就是它的明显含义。
因此，为了与服务交互，客户端使用他们都理解的超媒体格式，该格式可以是标准的、自行开发的或这些格式的混合（例如基于 XML/XHTML 的）。除此之外，它们还必须共享协议，很可能是 HTTP，但由于标准中省略了一些细节，因此必须有一些其用法的习惯用法，例如“使用 POST 创建资源并使用 PUT 更新” 。此外，此类协议将包括服务的入口点（同样，就可访问资源而言）。
这三个方面充分定义了域协议。特别是，客户端在开始使用服务之前不应该知道任何内部链接，也不应该在交互完成后记住它们。因此，内部导航的任何更改（例如重命名）/cakes to /f5d96b5c只要顾客遵守最初的协议并从前门进入商店，就不会受到影响。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
