3

我正在为我公司的内部数据设计一个 HATEOAS API，但在发现链接时遇到了麻烦。考虑以下一组步骤，让某人在此系统中检索有关特定员工的信息：

  1. 用户发送 GET 以http://coredata/获取所有可用资源，返回多个链接，包括一个标记为 rel = " http://coredata/rels/employees"
  2. 用户在第一个请求的 rel 上遵循 HREF，在（例如）执行 GEThttp://coredata/employees

最后一次通话返回的数据是我的难题，也是我听到不同建议的情况。这里是其中的一些：

  1. 该 GET 将返回所有员工（可能带有截断的数据），并且客户端将负责从该列表中选择所需的员工。

  2. 该 GET 将返回许多 URI 模板链接，描述如何查询/获取一名员工/获取所有员工。就像是：

    "_links": {
    "http://coredata/rels/employees#RetrieveOne": {
        "href": "http://coredata/employees/{id}"
    },
    "http://coredata/rels/employees#Query": {
        "href": "http://coredata/employees{?login,firstName,lastName}"
    },
    "http://coredata/rels/employees#All": {
        "href": "http://coredata/employees/all"
    }
}

我有点卡在这里最接近 HATEOAS 的东西。对于选项 1，我真的不想让我的客户每次都为了导航而检索所有员工，但我可以看到在示例 2 中使用 URI 模板如何引入一些带外知识。

我的另一个想法是使用 RetrieveOne、Query 和 All 操作作为我的酷 URL，但这似乎违反了您应该能够从一个基本 URI 导航到所需资源的概念。

有没有其他人设法想出一个很好的方法来处理这个问题？一旦您检索到一个资源或一组资源，导航就变得非常简单，但它似乎很难用于发现。

4

3 回答 3

3

选项 2 还不错，因为您使用RFC 6570来描述 URI 模式；虽然 HATEOAS 通常表示不让客户端合成 URI，但如果服务器准备对 URI 模板做出保证并以标准格式明确告诉客户端，这是可以接受的。（我很想让“列出所有员工”的 URL 不带all后缀，以便将其与具有该 ID 的员工区分开来；原则上，客户不应该知道员工 ID 的样子。）

事实上，主要问题实际上是客户端必须了解这些标记 URI 的含义；没有真正的方法可以猜测“<code>http://coredata/rels/employees#All”的意思是“列出所有员工”。这就是您在客户端、语义标签等中嵌入知识的地方，而 HATEOAS 并没有真正解决这些问题。

于 2012-11-25T12:16:50.467 回答
1

TL;DR：使用 OPTIONS 方法以编程方式返回可使用的文档并始终实现分页。

我们在我的工作中创建了许多内部 REST 服务。我们已经标准化了使用 OPTIONS 方法返回资源的元数据。我们返回的元数据充当该资源的可解析文档。它指示 url 模板、各种选项，如 PAGE、PAGESIZE 以及资源支持的不同方法。我们还返回 rel 链接，因此可以使用 OPTIONS 进行顶级资源发现，而无需拉取实际数据。

我们还专门实施了分页，以防止不必要地返回大量数据的问题。

于 2015-03-21T13:24:29.377 回答
0

我的 HATEOAS API 返回 HTML 以及HAL+JSON，正如您使用的那样，它们都使用相同的 URI，所以我的 JSON 响应只是返回人类网络用户会看到的内容（减去所有漂亮的颜色）。例如

GET /


{"_links": {
    "http://coredata/companies": { "href": "/companies?page=1" }
    ...
}}



GET /companies?page=1


{"_links": {
    "next": { "href": "?page=2" }
    ...
}}
于 2012-11-25T11:02:18.430 回答