问题标签 [hateoas]

对所有这些 REST 东西来说都是全新的。

我正在设计我的 API，但不确定我应该从搜索查询中返回什么。我假设我只会返回与查询完全匹配的所有对象，但是在阅读了一些关于HATEOAS的信息后，我想我应该返回一个 URI 列表吗？

我可以看到这可能有助于缓存项目，但我担心后续多个 HTTP 请求会产生大量开销以获取实际对象信息。

我是不是误会了？是否可以接受返回对象实例或 URI？

我很想知道其他人如何处理为他们的 Web API 生成超媒体链接的问题？具体来说，我正在使用 ASP.NET Web API，并且在让操作返回与超媒体相关的类型或返回资源本身以及让超媒体内容在管道中稍后发生之间左右为难。也就是说，人们是否倾向于做以下事情：

或者更像

然后在 HttpOperationHandler 或自定义格式化程序或其他东西中添加超媒体链接？

如果方法更像#2，你怎么知道要生成什么链接？只是有一些为所有 Order 对象生成的标准链接集？在 OrdersController 中装饰各种操作的属性？

我没有设法将 Jersey 链接支持与 Google App Engine 一起使用，我在尝试访问应用程序时遇到了这些异常：

如文档中所述，我将其放在 web.xml 的 Jersey servlet 部分：

我还将 jersey-server-linking-1.13.jar 添加到我的项目的 WEB-INF/lib 目录中。

我尝试先添加 el-api.jar，然后将 juel-2.1.0.jar 添加到 WEB-INF/lib 目录，但我仍然收到这些错误。

我想知道是否有人可以给我一些关于如何处理这个问题的提示。当我不使用 Jersey 链接 jar 时，一切都按预期工作。

假设我想创建一个类似于以下内容的 XML 响应：

给定一个如下所示的域模型：

以及类似以下的金钱阶层：

现在，我的问题。创建如下所示的响应非常简单

使用注解、XML 或 YAML 来告诉 JMSSerializerBundle 如何序列化产品对象。但是，实体不应指定xmlns:atomand条目，因为它不应该知道它的位置和位置。您还可以想象更多具有不同 - 属性的链接，例如. 想到的一种解决方案是一种服务，它监听特定对象的序列化事件，并根据需要添加这些属性和标签。该服务可以使用 DI 来获取, -service 等以适合所请求格式的格式生成这些链接。IE 在 XML 响应中，它可以将适当的类型设置为<atom:link>reledit
RequestRouterapplication/media-format+xml，而在 json 响应中，它可以生成类似

现在，在JMSSerializerBundle 的文档中，我找到了@PreSerialize和的注释@PostSerialize，但它们似乎只能调用被序列化对象的方法。
有谁知道如何/是否可以实现？还是我必须使用 Twig 等模板引擎并手动创建 XML 响应？

嗨，我想知道哪个是使用 ember-data 中相关资源的最佳解决方案。为了构建 REST 后端。

1) 嵌入式资源

2) 资源的嵌入 id

3) 链接资源

您认为可以像在 HATEOAS 中那样使用 hipermedia 吗？

提前致谢

构建 RESTful API 的关键点之一是 HATEOAS。现在，Jersey 提供了非常好的链接功能（请参阅此链接）。但我看过HAL 规范的草案，它似乎是一个经过深思熟虑的工作。

如果有一些库可以轻松地在泽西岛遵守 HAL，我很感兴趣。我已经看到了草案中提到的参考资料，例如https://github.com/HalBuilder。但我使用的是直接 POJO 编组，我不知道如何将它与 Halbuilder 混合。

那么，是否已经有一些将 HAL 纳入泽西岛的库？或者也许我可以使用某种过滤器来手动增强生成的 POJO？如果是的话，有人可以给我一个线索来完成这个任务吗？

我正在按照 HATEOAS / REST 原则设计一个 API。但是我不确定这个基本点：资源识别。

假设这个 url: /images 公开了用户上传的所有图像（给这个用户）。

假设我使用 oauth 访问令牌进行身份验证，/images 的内容将根据 Authorization 标头而有所不同。

这是否打破了资源概念的识别？

我正在尝试构建一个应该为我的 UI 提供动力的 RESTful Web 服务。如果我遵循纯粹的 HATEOAS 原则，我应该只在集合中公开单个资源的 URI。现在，假设我有一个父子关系，每个父级可以有大约 50 个子级，并且 UI 需要在单击父级时也显示所有子级的部分数据。

如果我只向父级公开子 URI，那么 UI 将必须进行 50 次 Web 服务调用才能完成此操作。另一种方法是拥有一个单独的 API，它将给出父级以及有关子级的部分信息，而不仅仅是 URI。我确信这是一个很常见的问题。这里的正确平衡是什么？有哪些陷阱？从设计的角度来看，“唯一的 URI”方法更简洁，但由于所有这些服务调用，它可能会使 UI 变得非常慢并给服务器带来大量负载。因此，另一种方法可能更实用。根据您的经验，哪个更好？

我有理由确定我了解 HATEOAS 设计的服务器端——在响应中返回状态 URL——但我对如何设计客户端来接受这些有点困惑。

例如，我们访问 //somehost.com/resource/1 上的资源 - 这为我们提供了资源数据和链接。我们假设返回到 //somehost.com/resource 的 POST，表示一个“新”操作。现在我知道将一些数据发布到该 url 会创建一个新资源并提供响应，但是发布该数据的表单在哪里？我已经看到 //somehost.com/resource/1/new 提供了一个 POSTS 到 /resource 的表单的实现，但是该 URL 本身包含一个动词，并且似乎违反了 REST。

我认为我的困惑在于我在同一个应用程序中实现了一个 RESTful API 和一个使用它的客户端。

这种事情有某种最佳实践吗？

让我们考虑一下我们有一个用于动物园的 api，../api/zoos它可以一直访问给定动物园中的个体动物，例如../api/zoos/123/elephants/234，每种动物类型都有明确定义的 api。
    现在，如果我们想查询超类型（抽象类 Animal where ），为此类元查询class Elephant extends Animal公开此类 api 是个好主意吗？../api/zoos/123/animals?type="mammal"&legs=4
    让我对这种方法三思而后行的是，虽然超类型 api 对于跨具体类型的元查询实际上很有用，但这本质上是一个只读查询，同样从可扩展性的角度来看，在超类型 Animal 和具体类型之间Elephant 可以有许多其他类型，如 Mammal、FourLegged 等，可以单独查询，然后需要调用是否需要在这些上公开只读 api，或者我们在动物查询中有类型参数就可以了。请建议。