问题标签 [hateoas]

我想使用查询参数设计一个 RESTful 搜索 URI。例如，此 URI 返回所有用户的列表：

获取/用户

以及姓氏为“Harvey”的前 25 位用户：

GET /users?surname=Harvey&maxResults=25

如何使用超媒体来描述“/users”资源允许的查询参数？我注意到新的Google Tasks API只是记录了参考指南中的所有查询参数。我会记录这份清单，但我也想用 HATEOAS 来做。

先感谢您！

我认为我对 RESTful 架构的原则有很好的把握，但我还没有做到。

我似乎无法弄清楚的部分是客户端如何知道每个资源可以使用哪些 HTTP 方法？当应用程序流程中需要特定操作来继续流程时，该怎么办？

简化示例：

假设客户向我的 REST API 下一个简单的订单。

客户端将向：http ://api.mycompany.com/orders 发出 post 请求

请求有效载荷

假设请求成功

响应负载

如果我正确理解了超媒体约束，我会提供相应的资源，客户可以选择从那里去哪里。

在上面的示例中，带有 rel="order" 的链接可以是GET、PUT或DELETE请求。rel="invoice" 的链接仅限于GET请求。rel="payment" 的链接只接受POST请求。

客户怎么知道这个？我知道如果他们向上述资源之一发出OPTIONS请求，它应该为他们提供可用的方法，但我不确定这是否是处理这种情况的标准方法。

任何帮助将不胜感激。

假设我正在关注 HATEOAS 并在我的 XML 中使用超文本。像这样的东西：

/客户/32

/地址/4324

是否有类似于 JAXB 的库或其扩展可以解组客户并自动查询和解组地址作为该客户的属性（如customer.getAddress().getStreet()）？如果不是，那么适合客户端缓存的好方法是什么？

我正在设计一个基于 JSON 表示的 RESTful API。为了遵守 HATEOAS，我广泛使用资源之间的链接。因此，我遵循了这个建议，以与 ATOM 链接非常相​​似的方式对链接进行序列化。

现在我有时在识别正确的链接关系类型时遇到问题。当资源包含指向自身的链接时，这种self关系是显而易见的。当资源是子资源的集合和聚合，或者包含许多指向相关资源的链接时，它会变得更加复杂。

以一篇博文为例，想想一个返回博文快照的资源——包括这篇博文的作者、标签和评论。显然，该资源包含许多子资源，当然还应该提供指向它们的单独链接：

样本资源：

那么给定链接的适当关系是什么？我知道有诸如 的关系类型tag，但并非我的所有资源都与现有的关系类型匹配。还是self在引用作者/标签/评论时可以使用，因为它与封闭的 JSON（子）对象的上下文有关？语义实体self指的是什么？

RFC 5988 指出：

链接的上下文是提要 IRI 或条目 ID，具体取决于它出现的位置

我如何用 JSON 来解释这一点？每个新对象{…}都是一个新的上下文吗？

谢谢！

我正在努力使用HATEOAS实现 Spring MVC 3.x RESTful 服务的正确方法。考虑以下约束：

• 我不希望我的域实体被 web/rest 结构污染。
• 我不希望我的控制器被视图结构污染。
• 我想支持多个视图。

目前我有一个很好的 MVC 应用程序，没有 HATEOAS。域实体是纯 POJO，没有嵌入任何视图或 web/rest 概念。例如：

我的控制器也很简单。它们提供路由和状态，并委托给 Spring 的视图解析框架。请注意，我的应用程序支持 JSON、XML 和 HTML，但没有域实体或控制器具有嵌入的视图信息：

所以，现在我的问题 - 我不确定支持 HATEOAS 的干净方式。这是一个例子。假设当客户端请求一个 JSON 格式的用户时，它会像这样：

还假设当我支持 HATEOAS 时，我希望 JSON 包含一个简单的“自我”链接，然后客户端可以使用该链接来刷新对象、删除它或进行其他操作。它还可能有一个“朋友”链接，指示如何获取用户的朋友列表：

不知何故，我想将链接附加到我的对象。我觉得这样做的正确位置是在控制器层，因为控制器都知道正确的 URL。此外，由于我支持多个视图，我觉得正确的做法是在控制器中装饰我的域实体，然后再将它们转换为 JSON/XML/Spring 的视图解析框架中的任何内容。一种方法可能是使用包含链接列表的通用 Resource 类包装有问题的 POJO。需要进行一些视图调整才能将其压缩成我想要的格式，但它是可行的。不幸的是，嵌套资源不能以这种方式包装。想到的其他事情包括添加到 ModelAndView 的链接，然后自定义 Spring 的每个开箱即用的视图解析器以将链接填充到生成的 JSON/XML/等中。我不做什么 不想要的是不断手工制作 JSON/XML/等。以适应开发过程中来来去去的各种链接。

想法？

我正在使用 RestEasy 2.2.2 开发 JAX-RS 网络服务，以部署在 Tomcat 7 上。网络服务将 JSON（通过 Jackson）返回给客户端。到目前为止我得到了它，但我不确定如何构建需要发送给客户的动态链接。

我想到了以下内容：

1-制作根对象的深层副本（它本身包含其他对象，总共三个级别），修改表示链接的字符串属性，并返回这个新对象。

关注点：性能，让深拷贝实现正确

2-根据请求修改对象并返回

关注点：并发问题（我什至不确定这是否可能）

3-构建一个新的根对象，迭代“主对象”并根据需要修改/添加

关注点：类似于（1）。基本上，这是实现一个复制构造函数与 cloning() 对象。

我能找到的唯一示例（向下滚动到“JAX-RS 资源类”部分）似乎实现了选项 3。但是，如果我没记错的话，它的行为也类似于选项 2（它修改对象并添加到集合中) 而且我不确定如何处理并发问题。

提前感谢您的任何指导、帮助和意见。

我试图澄清一个与 REST 可发现性相关的概念——即是否满足 RESTful 服务的 HATEOAS 约束意味着现在 URI 可以更改，因为它们是可发现的并且没有记录。

这似乎没有遵循酷 URI的概念——URI永远不会改变的事实。它也与网络本身的模型有些不一致（REST 本质上应该非常适合）——URL 是可收藏的并且永远不会改变的事实，以及一旦你学会了一个，你就可以直接进入它并且你做的事实不必每次都经过根目录并发现它。

对此的任何反馈表示赞赏。

例如，在构建我的 Web 服务的 RESTful API 时，我试图为客户端提供链接关系（这是 GET 入口点返回的内容）：

我希望客户明白，为了发布一篇新文章，他必须提交一个 POST 请求/post-new-article作为"text"查询参数。

但是我没有"POST"在文档中说什么，也没有告诉他我期待的是哪个 HTTP 查询参数。我应该如何以及在哪里提供这些信息？是否有任何事实上的标准/约定？

如果我有一个 RESTful 服务，该服务通过端点具有可发现的资源，例如：

要求：

回复：

然后有了这个响应，客户端可以跟随其中一个超媒体链接：

要求：

回复：

第一个响应可能会不太频繁地更改（例如：很多个月），而第二个响应可能会稍微更频繁地更改（例如：每个月左右）。对于这种情况，什么是好的 HTTP 缓存策略？按日期，客户 ETag 比较，还有别的吗？

编辑：如果数据在一天左右的数量级上是陈旧的，那很好。再多的话可能会有问题。

我正在开发一个通过 Web 服务与（Java）后端通信的富互联网 Web 应用程序。我在 Flex/Flash 和 GWT/Javascript 中都对用户界面进行了原型设计，并注意到这些 RIA 平台倾向于支持 RPC 样式的后端通信方法（AMF 用于 Flex，GWT-RPC 用于 GWT）。

就我而言，服务器还需要为我未编写的其他客户端提供 Web 服务。因此，我倾向于基于标准的 Web 服务（例如 SOAP 和 REST）。我相信 RIA 必须使用我们为其他人提供的相同网络服务。我“得到”了 SOAP，因为它模拟了我从经验中熟悉的 RPC 样式。我是 REST 新手，但使用 CXF/Jackson 对 REST 后端进行了原型设计。然而，此时我的 REST API 仍然感觉像是一个 RPC 样式的 API，我意识到这是因为我无法理解 HATEOAS 的想法。

我已经阅读了大约 10 次Roy T. Fieldings 有用的博客文章，我想我开始看到曙光了。例如，我很清楚，如果我要在我的资源中包含指向各种状态转换的链接，我真的可以减少我的客户端和服务器之间的耦合量。我的客户可以只渲染按钮，让用户可以访问当时可以在显示的实体上执行的合法操作。

但是 RIA 与其服务器应用程序之间的松散耦合是否重要？

就其本质而言，RIA 与服务器数据模型非常紧密地耦合在一起。开箱即用，它们预设了很多东西。我猜这就是为什么他们也更喜欢 RPC 风格的应用程序协议……因为松散耦合不是设计目标。但我开始意识到，如果我们认真对待 HATEOAS，我们可以编写一个更通用的 RIA 客户端，对可以执行的数据模型和操作做出很少的假设。这可以减少通过更改后端来维护客户端的工作量，但这有意义吗？收益是否大于成本？

ps - 还有两个细节——这个应用程序有一个极其复杂的、深度嵌套的数据模型。此外，如果有人告诉我我们不是 100% 纯 REST Web 应用程序，我也不会在意。