Web services 如何在用于GUI应用的HATEOAS API中处理全局超媒体？

编辑：为了澄清，这个问题涉及在HATEOAS API上构建GUI应用程序，如何设计基于超媒体“可发现性”（即动态）原则构建的界面，以及具体处理避免纯粹的“模式”GUI“链接”回“主页”，以实现应“始终打开”的全局功能（由超媒体入口API点表示）

---

在严格的REST API实现中，使用超媒体作为应用程序状态引擎（HATEOAS），使用了哪些模式（如果有的话）来指示/表示全局“始终有效”的操作（如果REST确实存在这样的概念）

元问题是，你能“排除”重复的超媒体吗

通过简化的示例，假设我们有一个资源

/version

，其中包含

允许：选项HEAD-GET

。此资源不依赖任何内容，也不受其他地方可能发生的任何有状态转换的影响

是否要求超媒体只需与每个其他资源请求一起发送

或者是另一种模式，客户端行为链接回

主页

（可能是缓存的），然后触发始终有效的

/version

调用？（GUI术语中的“模式”模式-关闭此资源，返回主页，然后继续）

或者是否有某种方法/模式可以为任何给定的应用程序创建独立的解耦模块？（可能是某种名称空间？）

在一个复杂但松散耦合的API中，选项1最终被埋没在超媒体地狱中，每次资源调用都会重复80-95%的有效负载。这似乎是“正确”的，但非常糟糕。选项2会导致GUI客户端行为中出现奇怪的怪癖（在“返回”之前隐藏有效元素-模式类型ops）或者GUI客户端的许多非restful假设硬编码它“知道”的带外操作总是有效的

---

选项3与我最初的问题有关：是否有一个标志或其他模式用于指示可以发送一次（比如使用根/主资源）然后“分解”的全局有效操作接下来的响应是什么？

也许我误解了这个问题，但客户端缓存似乎应该可以解决这个问题。查找Expires和Cache Control标头。

好吧，这里发生了一些事情

首先，您可以简单地添加一个链接到您常用的“全局”资源中。尽管我不喜欢将REST体系结构与Web站点进行比较，但是Web站点是一个合适的例子。考虑这里的许多资源，以便链接到“全局”资源（如主页、问题、标签、徽章和/或用户）。 一个资源是“静态”且从不更改的事实对您是否通过另一个资源（作为HATEOS的一部分）将该资源作为链接提供没有影响，这是一个正交问题

第二点是，没有任何东西表明整个服务可以从每个资源持续访问。您的服务中可以有“众所周知”的入口点，这些入口点可以很好地记录（外部）。唯一的缺点是，如果某个关系的URL发生更改（/questions to/questions-2，例如），则客户端可能不会自动拾取这些URL。但这可能不是问题，因为更改URL可能会更改影响客户端的其他内容（如负载），从而导致旧客户端可能与新URL不兼容

让客户端“知道”东西在嵌套系统中的位置也不是问题。例如，如果他们“知道”，如文档所述，他们只能从/home资源访问/version，并且每个其他资源都有一个到/home的路径（直接或间接），那么这也不是问题。当它想要/version时，它应该知道获得它的路径

只要客户端是根据您告诉它的内容而不是“它认为”的内容来遍历图形，那么一切都很好。如果客户端当前正在处理/blog/daily_news/123资源，并且它有一个指向“parent”的链接rel，该链接的url为/blog，/blog有一个指向/version的链接rel，则客户端可以遍历图形（遍历父rel to/blog和版本rel to/version）。客户端不应该做的是（除非另有说明），它不应该假设它可以随时访问/version。因为它不是从/blog/daily_news/123链接的，客户端不应该直接跳到它。rel不在那里，所以客户端“不知道”

这是关键点。事实上，它不在那里意味着它现在不是一个选项，不管出于什么原因，强制执行这一点不是客户端任务，因为URL空间不在它的手中，它在服务的手中。服务控制它，而不是客户端

如果/version突然消失，那么，这是另一个问题。也许他们超时了，不允许再“查看/version”，也许你删除了它。此时客户端只会出错“找不到版本rel”，然后退出。这是一个无关的问题，只是事实而已（当资源突然在你背后消失时，你还能做些什么）

问题增编：

---

如果我理解这意味着：如果/home没有过期，我们 导航到/blog（其中包含返回/主页的rel），然后浏览rel 在/home中的方法仍然可以从/blog中立即“访问”，对吗

不，不是真的。这是关键点。除了一些专门记录的全局资源（带外），您不应该遍历到当前资源中未指定的任何链接。/home是否过期根本不相关

服务器当然可以发送适当的缓存指令，让您知道可以缓存/home一段时间，但您应该