api - 超媒体API链接遍历与实用性

Question

关闭。这个问题需要details or clarity .它目前不接受答案。












想改善这个问题吗？通过 editing this post 添加详细信息并澄清问题.

8年前关闭。




Improve this question




我一直在尝试构建基于超媒体的 API。事情似乎运作良好。当我取货时说 /books/isbn/12313441213我得到这样的东西:

<book>
  <id>123</id>
  <name>Hypermedia APIs</name>
  <description>Basic api design techniques</description>
  <tags>
    <tag>rest</tag>
    <tag>api</tag>
    <tag>service</tag>
  </tags>
  <authors>
    <link rel="author" uri="/authors/id/22" />
    <link rel="author" uri="/authors/id/18" />
  </authors>
</book>

现在我可以从这个资源遍历作者。当我获取 /books/by/author/id/18我得到这样的东西:

<books>
  <book id="123">
    <name>Hypermedia APIs</name>
    <link rel="self" uri="/books/id/123" />
  </book>
  <book id="191">
    <name>Chef Recipes for Rails Developers</name>
    <link rel="self" uri="/books/id/191" />
  </book>
  <book id="220">
    <name>Rails 4 Cookbook</name>
    <link rel="self" uri="/books/id/220" />
  </book>
  <book id="292">
    <name>Ruby 102</name>
    <link rel="self" uri="/books/id/292" />
  </book>
  <book id="432">
    <name>Semantic Architecture</name>
    <link rel="self" uri="/books/id/432" />
  </book>
  <book id="501">
    <name>Service Oriented Design</name>
    <link rel="self" uri="/books/id/501" />
  </book>
</books>

这对我来说似乎也很好。这种 uri 模板化方式是否好，我的问题是遍历这样的链接有多实用？

考虑到您想要全面深入的资源(包括作者详细信息)，您必须至少对服务器进行 3 次调用。再次收集，您必须对服务器进行大量调用。是的，也许我可以在这里利用资源扩展，但是我为什么要使用超媒体链接，因为我的所有客户都会及时使用扩展资源。

我知道我们通过让客户端遍历链接获得了很多 yield (即，如果客户端构建基于关系的资源发现，那么当我们更改 api 时，他们将受到的影响最小，或者他们被迫从资源端点本身获取最新的架构，等等)。再说一次，这种方法的实用性，或者这种方法的性能会杀死系统。

要么我在超媒体 api 设计中没有得到任何东西，要么超媒体 api 听起来很棒，但它似乎只是一个理论想法，而不是实际想法。

对此有何想法？

Answer 1

这一直是一个很好的问题。事实上，另一个大问题是:谁知道到达特定资源 R 的遍历 rels？

例如，要访问“book-detail”资源，客户端必须调用 api 的条目，例如“/”，然后使用 rel“book-categories”获取 uri 到 book-categories，然后调用 OPTIONS查看是否可以对该资源进行 GET 操作，然后获取书籍类别，然后获取“书籍类别”资源的 rel 等，最终转到“书籍详细信息”资源。到资源 R 的遍历路径应该是客户端知识的一部分。但是不要对网址进行硬编码，只需在运行时读取网址即可。这是在考虑机器对人的场景。
效率低下仍然存在。
在机器对机器场景的情况下，以“/”开头的自动机可以通过您的 API 并对您的资源进行某些处理。如果自动机必须访问树中的所有资源(或者可能是状态机)，那么就没有效率低下。但是如果自动机需要调用树中的资源，并且它只知道 API 的入口点，那么它将遇到进行多次调用以到达它的点的问题。

很多人会告诉你使用 etags 和/或 memcached 来引入缓存，但是缓存是为了提高性能，你不能 100% 依赖缓存，因为缓存变得陈旧，所以在这些情况下，遍历资源 R1 到 Rn 的代码应该在你的客户。

检查我的问题:https://stackoverflow.com/questions/15214526/why-hypermedia-api

但是要回答您关于实用性的问题:如果您有一个业务工作流程，其中客户需要转到资源 R1 然后是 R2 然后... Rn 并且您想强制执行该流程，超媒体是实用的。我假设没有直接调用 Resource Rx 而不通过 R1 -> R2 ->... Rx-1。