Questions tagged «hateoas»

最近，我一直在阅读有关作为应用程序状态引擎（HATEOAS）的Hypermedia的信息，据称该约束使Web API成为“真正的RESTful”。它归结为基本上包括链接，这些链接包含对从当前状态可能进行的转换的每个响应。 让我根据自己的理解来说明HATEOAS是什么-如果错过任何事情，请纠正我。 / GET: { "_links": { "child": [ { "href": "http://myapi.com/articles", "title": "articles" } ] } } /articles?contains=HATEOAS GET: { "_items": [ { "uri": "http://myapi.com/articles/0", "title": "Why Should I Care About HATEOAS?" }, { "uri": "http://myapi.com/articles/1", "title": "HATEOAS: Problem or Solution?" } ], "_links": { "self": { "href": …

61 rest  http  hateoas 

据我目前的了解，HATEOAS基本上是与每个响应链接一起发送以及下一步操作的信息。在互联网上可以轻松找到一个简单的示例：银行系统和帐户资源。该示例显示了对帐户资源的GET请求后的此响应 GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">100.00</balance> <link rel="deposit" href="/account/12345/deposit" /> <link rel="withdraw" href="/account/12345/withdraw" /> <link rel="transfer" href="/account/12345/transfer" /> <link rel="close" href="/account/12345/close" /> </account> 连同数据一起，有链接告诉下一步可以做什么。如果余额为负，我们有 GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">-25.00</balance> <link rel="deposit" href="/account/12345/deposit" /> </account> 这样我们只能存款。很好，如果我们使用Fiddler或通过浏览器发出请求，我们可以轻松地看到可以做什么。这样的信息对于我们发现API的功能以及服务器与客户端的分离非常有用。 但是，要点是，当我们构建客户端（例如带有Javascript的SPA或Android应用程序或许多其他东西）时，我看不到HATEOAS如何继续发挥作用。我的意思是：当我用javascript编码SPA时，我必须知道可以在API中完成什么才能编写代码。 …

35 rest  client-server  hateoas 

我看过的各种讲​​座以及我在REST上扫描的教程似乎都在强调一种称为“可发现性”的东西。据我有限的理解，该术语似乎意味着客户应该能够http://URL-自动获得其可以做的事情的清单。 我难以理解的是-“软件客户”不是人类。它们只是程序，没有直观的知识来理解与所提供的链接的确切关系。只有人可以访问网站并理解所显示的文本和链接并对其进行操作。 那么，当访问此类可发现URL的客户端代码实际上无法对其进行任何操作时，除非客户端的人工开发人员实际尝试了所提供的资源，可发现性的意义何在？这看起来与在《文档》手册中定义可用功能集完全一样，只是方向不同，实际上需要为开发人员进行更多工作。为什么第二种预定义可以在实际REST资源外部的文档中完成的工作的方法被认为是次等的呢？

20 rest  api  hateoas 

如果我理解正确，那么REST被Roy Fielding正式化为Web体系结构的描述性模型。AFAIK Fielding并不认为REST很好，他只是在描述Web的实际架构。在这一点上，网络已经证明了一个巨大的成功的分布式超文本系统，因此，这种验证将REST作为主要由人类导航和使用的分布式超媒体领域的成功架构。 REST Web服务是通过将REST体系结构应用于API来创建的。但是实际上是否有任何理由认为REST是该领域的理想架构？更具体地说，是否有证据表明HATEOAS是机器对机器通信的有益设计原则？ 我担心的是HATEOAS对于超媒体有意义，因为很少有众所周知的内容类型（HTML，图像，视频等），并且客户端知道如何使用它们。但是对于API来说，内容类型是非常特定的，并且如果客户端经过专门编程以使用它们，则客户端只能以有意义的方式使用它们。向客户端返回URL本身并不能使客户端能够使用指示的资源。

15 rest  hateoas 

在使用HATEOAS约束构建REST服务时，通过链接宣传存在的资源非常容易。您GET以我的网站的根目录为基础，然后我以列出所有第一层资源的根目录文档进行响应： { users: { href: "/users" } questions { href: "/questions" } } 了解如何读取这些href值的客户端可以对这些值执行GET请求，并发现应用程序中所有可用的当前资源。 这对于基本的查找方案非常有效，但不能指示资源是否可查询。例如，执行以下操作可能是合理的： GET /users?surname=Smith 是否有任何格式可以用足够的信息来表达此查询功能，以使客户端无需事先了解资源就可以形成连贯的查询？ 另外，有什么方法可以表示允许客户端POST对具有预期位置的给定位置执行操作。例如，可以期望客户执行以下操作来创建新的问题资源： POST /questions { title: "Are there strategies for discovering REST services using HATEOAS?", body: "When building a REST service with the HATEOAS constraint, it's very..." } 当使用HTML作为人类消费的格式时，我们可以通过使用表格和书面提示来表达很多这种形式，以使人们能够发现他们被允许对服务执行的操作。 是否有能够为客户提供类似功能的格式？

10 design  rest  hateoas