问题标签 [hypermedia]

HAL 规范说：

注意：如果您不确定链接是否应该是单数，请假设它是多个。如果您选择单数并发现需要更改它，您将需要创建新的链接关系或面对破坏现有客户。

与特定 rel 单数或复数建立链接是否仅适用于在特定资源表示中使用该 rel，还是适用于在任何资源表示中使用该 rel？

例如，如果我决定itemrel 下的链接在某个资源 X 中应该始终是多个，那么该约束是否仅适用于资源 X，或者如果我碰巧在那里使用它也适用于资源 Y item？

这个问题与语言无关。让我们不要担心框架或实现，我们只是说一切都可以实现，让我们以抽象的方式看待 REST API。换句话说：我现在正在构建一个框架，但我在任何地方都没有看到任何解决这个问题的方法。

问题

如何为返回集合的两个独立 REST 路径的交集构造 REST URL 端点？简短的例子：如何相交/users/1/comments和/companies/6/comments？

约束

所有端点都应返回单个数据模型实体或实体集合。

恕我直言，这是一个非常合理的约束，所有超媒体 API 示例看起来都是这样的，即使在draft-kelly-json-hal-07中也是如此。

如果您认为这是一个无效的约束，或者您知道更好的方法，请告诉我。

例子

因此，假设我们有一个具有三种数据类型的应用程序products：categories和companies。每个公司都可以将一些产品添加到他们的个人资料页面。在添加产品时，他们必须为产品附加一个类别。例如，我们可以像这样访问这种数据：

• GET /categories将返回所有类别的集合
• GET /categories/9将返回 id 9 的类别
• GET /categories/9/products将返回 id 9 类别内的所有产品
• GET /companies/7/products将返回所有添加到 id 7 公司简介页面的产品

我_links故意省略了超媒体部分，因为它很简单，例如/给等。我们只_links需要记住，通过使用超媒体，我们正在遍历关系图。/categories/companies

如何编写将返回的 URL：来自公司（7）且属于类别（9）的所有产品？换句话说，如何相交/categories/9/products和/companies/7/products？

假设所有端点都应该代表数据模型资源或它们的集合，我相信这是 REST 超媒体 API 的一个基本问题，因为在遍历超媒体 api 时，我们正在沿着一条路径遍历关系图，因此不可能描述这种交集，因为它是两个独立图路径的横截面。

换句话说，我认为我们不能只用一条路径来表示两条独立的路径。通常我们会像 一样遍历一条路径A->B->C，但是如果我们有X->Y并且Z->Y我们想要所有Y来自的 s，X那么Z我们就会遇到问题。

到目前为止，我的建议是使用查询字符串：/categories/9/products?intersect=/companies/9但我们能做得更好吗？

我为什么要这个？

因为我正在构建一个框架，它将基于 SQL 数据库关系自动生成 REST 超媒体 API。您可以将其视为SELECT ... JOIN ... WHERE查询 URL 的反编译器，但 API 的客户端只看到超媒体，并且客户端希望有一种很好的方式来进行交叉，就像在示例中一样。

我目前正在设计超媒体 REST API。我想知道是否有关于在 GET 请求中将电子邮件地址作为 URL 参数传递的建议。

提前致谢

我知道一些流行的超媒体格式，例如 HAL、UBER 和 Collection+JSON，我确实看到了这些格式的价值，但是如果我想在出现错误响应的情况下简单地添加建议的 URI现有的基于 HTTP 的 API 这样做的合理方式是什么？我宁愿不只是自己编造一些没有标准的东西，但另一方面，我也不打算在那个时候推翻 API。此外，在浏览一些流行的超媒体格式的细节时，我没有看到任何具体建议如何呈现与错误案例相关的相关链接的示例。

我想支持的一个示例用例类似于对格式为 /documents/vehical-listing 的 URL 的 POST 的响应，其中列表缺少所有者属性，我想将消费者指向一个诸如 /vehical-owners 之类的 URL，以便他们在尝试发布需要引用注册所有者的车辆列表之前知道在哪里发布所有者信息。

我在 API url 的基础中使用了一个变量，与Django REST Framework文档中的设置相同：

基本品牌 slug 之后的所有内容都是标准 API 格式，因此我使用 ModelViewSets 为我的对象生成所有列表和详细视图。API 中的所有内容都由品牌过滤，因此这种设置是有意义的。

简化项目/urls.py

简化的 api/urls.py

我还需要所有模型的超媒体链接，这就是我遇到问题的地方。REST 框架不知道如何获取这个品牌变量并使用它来生成正确的链接。尝试通过遵循文档来解决这个问题给我留下了两个挫折：

1. 虽然文档解释了如何覆盖 HyperlinkRelatedField 类，但他们从未说明将那个类放在哪里以便它与我的序列化程序一起使用。
2. 没有提及如何将品牌变量从 URL 实际获取到 HyperlinkRelatedField 类中。

这里缺少什么元素？

有很多超媒体可用于宁静的 api。我不确定哪个适合哪种情况。这是我第一次尝试restful api，所以我无法预见使用它的问题和优势。我想要的是可以查询并且还具有批处理支持（特别是对于 GET 请求）。

Odata 似乎功能完整，也是 oasis 标准，但对我来说似乎有点矫枉过正。它的查询能力灵活而复杂。更重要的是，没有任何 odata 4 的 php 实现。如果我使用它，我需要自己做。我现在正试图避免这种情况。

哈尔 做任何事情似乎都太简单了。

集合+json看起来不错。但似乎没有任何批量操作能力

jsonapi：看起来很简单。具有查询能力和批处理操作（带扩展名）。但它不支持 GET 请求的批量操作。它也处于稳定状态。但我还没有找到任何评论。

您对此有何经验？我应该如何选择其中的超媒体？任何见解都会有所帮助。我还想听听除此之外的任何其他超媒体。

目前我对 json-api 和 collection+json 感到困惑。

在JSONAPI 规范中，在 Resource Objects 下，它给出了以下资源示例：

如果我不使用资源包含，我的客户应该如何处理包含在以下内容中的信息：

响应包含指向article的作者 ( /articles/1/author) 的链接 - 通过阅读data { ... }响应的元素，我可以看出本文的作者是拥有 的人id=9，但我实际上无法对这些信息做任何有用的事情。

我可以使用此信息发出 GET 请求以/people/9检索作者详细信息，这似乎很直观，但这似乎不是 JSONAPI 规范的一部分（尽管有关于资源集合 URL的建议）

内联type/id信息是否仅在资源包含或与某些先前缓存的响应数据交叉引用的上下文中相关？或者是否有关于翻译type+id成资源 URL ( GET /{type}/{id}) 的未记录约定？

我想在模板引擎的帮助下生成有效的 JSON。特别是，我希望引擎将模板中的占位符替换为模型类的属性。引擎应该允许使用转换器来处理复杂的类，例如java.util.Date. 此外，我不想在模板本身中显式处理列表，而是希望任何类似集合的类型都能生成有效的 JSON 数组。

这可能是一个模板的例子：

我想从具有关系、名字和姓氏属性的模型中替换此模板中的变量 ( $relations, $firstname, )。$lastname这也适用于嵌套属性。（例如$address.street：）

绑定模型后，JSON 可能如下所示：

请注意，引擎需要注意在必要时使用引号。

是否有任何模板库能够做到这一点，或者我需要推出自己的库？

我已经查看了以下库：

• 自由标记
• 速度
• 字符串模板

我还阅读了几个线程：

• 类似于 ZPT（属性语言）的 Java 模板库
• 用于渲染 JSON 的 Spring 模板引擎

但是，到目前为止，我还没有找到令人满意的解决方案。

背景资料：

Uber是与领域无关的超媒体格式，它嵌套data元素以对数据进行编码。如果您想使用 Jackson 这样的库对其进行序列化，则这种格式的生成非常麻烦，因为您必须创建大量对象并通过 setter 将它们嵌套，这会导致大量代码并且也很容易出错。

这就是为什么我想到使用模板来生成输出并让用户编写模板，然后将模型绑定到该模板以生成输出的原因。

我正在使用spring-hateoas:0.18.0.RELEASE和spring-boot:1.2.5.RELEASE

为了调用我的 Web 服务并通过HAL链接，我正在使用Traverson 客户端 （受 Traverson JavaScript 库启发的客户端服务遍历 API）

Spring Hateoas Traverson 文档

使用超媒体和HateoasRest的新功能

我的问题是我什么时候需要使用PagedResources和Resource？

我在这里找到的示例 Traverson 客户端示例：

我写的代码是：

我知道这不是一回事，但是在调用Traverson.toObject()方法时，资源的最佳做法是什么？

Option 1:

Return as many links as there are resources.

It can see it being useful in the case we've already been caching some of the player resources on the client side.

Option 2:

Return a single link leading to the list of resources.

It looks a lot cleaner, and we can fetch the players in one request.