试图了解REST HATEOAS:
假设我有一个有状态的服务;他们是:初始,准备好,正在运行。我有一个连接到服务的客户端,获取一个页面,其中包含允许它改变服务状态的链接。
它使用其中一个链接来更改服务的状态,并获得另一个带有新链接的页面。
只要有1个客户端,客户端持有的状态与服务相同。但是如果有第二个客户端并且它改变了服务的状态,那么第一个客户端的表示就是陈旧的。
在HATEOAS中如何解决这个问题?从我所看到的,似乎REST不适用,我应该看看别的东西。如果是这样,是什么?
谢谢!
答案 0 :(得分:0)
HATEOS(完全)没有解决这个问题。由于REST是无状态的,因此这是一种悖论用例,可以使客户端和服务器中的状态保持一致。
假设我理解您的要求,是的,您在客户端1中的状态是陈旧的,与服务器上的状态不同。但是,如果客户端定期调用服务器以查看其他客户端是否更改了该怎么办?如果是这样,使用HATEOAS,您可以提供一个链接来提供当前状态,并省略链接以更改状态。
答案 1 :(得分:0)
@Kay - 感谢您的回答。
我将尝试回答我自己的问题。我在阅读完答案后意识到,HATEOAS中的“应用程序”实际上是客户端在检索和处理从服务器获取的资源时所经历的虚拟应用程序。它的状态是它之间转换的页面(资源)。服务器(服务?)可能有自己的状态,但它与客户端不同。
只要记住这种区别,在客户端1中使用陈旧链接并不是不合适的。服务器只是用反映其自身状态的新链接进行响应。客户端根据更新的链接进行新的转换。
仍在努力理解。如果我错了,我会感激一些帮助。
谢谢!
答案 2 :(得分:0)
REST的无状态要求是指服务器理解和处理客户端请求的能力,与之前与客户端进行的任何交互无关。换句话说,客户端应该能够“出乎意料地”向服务器发送请求(即,没有在所述服务器上保存会话)并且处理该请求。因此,在纯RESTful架构中没有登录和注销的概念。
这是与HATEOAS不同的约束。基本上,“超媒体作为应用程序状态的引擎”意味着所有状态都是通过正在使用的媒体类型而不是连接本身来传达的。客户端可以(并且经常)保持自己的状态,并可以通过资源表示(a.k.a媒体类型)从服务器请求资源状态的快照。
如果您希望在资源更改状态时收到通知,则REST(可能)是错误的选择。您可能希望使用与HTTP不同的应用程序协议。
答案 3 :(得分:0)
正如菲尔丁所说:没有HATEOAS,它不是REST。如果忽略HATEAOS并且有状态服务不能是REST,请不要调用您的服务REST。你了解HATEOA。服务器为客户端提供超链接,用于更改位于客户端的状态。
解决您的问题:从任何状态信息中省略tend服务器。它会让你的生活更轻松。然后使用Richardson成熟度模型实现REST,同时从这里考虑信息。