RESTful API是否应该避免要求客户端知道资源层次结构？

Question

我们API的入口点有一个名为“ x：reports”的关系（其中x是通过Curie在HAL表示中定义的前缀-但这现在并不重要）。

报告有几种类型。 以下“ x：report”提供了一组这些优惠，每个优惠都有其自己的关联-一个关联被称为“ x：proofofplay”。 有一组与此类型的报告（只有这种类型的报告）相关联的查找值。 由以下“ x：proofofplay”返回的表示形式与这组值“ x：artwork”有关。

这导致以下层次结构

reports
  proofofplay
    artwork

尽管“ x：artwork”资源很小，但确实需要一些时间来获取它（10秒）。 因此，客户端选择在应用启动时异步加载它。

为了获得“ x：artwork”的href，客户必须遵循链接。 我不确定这是否有问题。 由于客户端依赖于对该资源路径的带外知识，因此看起来可能不太RESTful。 如果艺术品的路径发生改变（极不可能），则客户会破产（尽管hrefs本身可以随时更改而不受惩罚）。

要了解我为什么担心，启动功能如下所示：

launch: function () {
    var me = this;
    Rest.getLinksFromEntryPoint(function(links) {
        Rest.getLinksFromHref(links["x:reports"].href, function(reportLinks){
            Rest.getLinksFromHref(reportLinks["x:proofofplay"].href, function(popLinks){
                me.loadArtworks(popLinks["x:artwork"].href);
            });
        });
    });
}

路径的这种硬编码同时使我认为“很好-它基于已发布的资源模型”和“我敢打赌Roy Fielding会生我的气”。

这样很好，还是让客户有更好的方法安全地导航这样的层次结构？

Answer 1

HAL对此的答案是嵌入资源。

视您的服务器端技术而定，这在您的情况下应该足够好，因为您需要在应用程序启动之前将所有数据存储在其中，并且由于担心按顺序执行此操作，因此可以在服务器上并行执行此操作。

理想情况下，您的HAL客户端应该将_links事物和_embedded中的事物视为同一类型的事物，除了在第二种情况下，您还正在为资源填充HTTP缓存。

我们基于js的客户端执行以下操作：

var client = new Client(bookMarkUrl);
var resource = await client
  .follow('x:reports')
  .follow('x:proofofplay')
  .follow('x:artwork')
  .get();

如果在_links中指定了这些中间链接中的任何一个，我们将跟踪这些链接并按需执行GET请求，但是如果在_embedded出现任何中间链接， _links跳过该请求并使用本地缓存。 这样做的好处是，将来我们可以将_links新内容添加到_embedded ，并加快不需要了解此更改的客户端的速度。 都是无缝的。

将来，我们打算从HAL的_embedded切换为使用_embedded Push。