超媒體API-直接請求是否是反模式？

Question

我正在使用Hypermedia概念設計API。 我看到這是一個好習慣，它有一條根路由返回其他API鏈接進行導航。

例如：我向http://myapi.com提出了請求，並且返回

{
  links: [
    { 'rel': 'profile', href: '/profile' },
    { 'rel': 'orders', href: '/orders' },
    { 'rel': 'order_types', href: '/order_types' },
    ...
  ]
}

但是，以這種方式，如果根擁有20個資源，它將非常大。

那么，直接向order_types發出請求，而不是向root請求，然后再請求order_types是一種反模式嗎？

Answer 1

這個問題很難回答，因為我想到的第一件事是：它真的那么大嗎？

現在，例如，每個鏈接大約需要40個字節。 對於20個資源，即800個字節。 gzip響應（如果可以支持，則為brotli），可以將其縮小。 如果您的總文件有一些開銷（例如，另外200個字節），並且我們假設為1KB，則使用gzip之類的文件，您可以將其放回400個字節或更小。

您可以在此文件上設置緩存標頭，以便它在藍月亮中僅被請求一次。

所以，現在您的主要問題是？ 是反模式嗎？ 我會說是的，您應該只有一個帶有書簽的網址。

Answer 2

由於我目前在大規模HATEOAS風格的REST API下遭受了很多苦難，因此，從我自己的角度出發，請幫自己一個忙，並將所有鏈接（方法）放在起始頁上。

您確實不想跟隨幾個鏈接來查找要使用（或測試）的方法。 當然，您可以使用直接路徑，但是再次使用它只是RPC樣式。

正如我很遺憾地說的那樣，HATEOAS的整個概念雖然聽起來並不糟糕，但在實施和測試方面確實是一個痛苦。