1

我正在设计一个 REST API，多个客户端将使用它来查询数据存储库。我预计这些客户会对回复的数量/详细程度有不同的需求。

假设我可以查询一组书籍。一本书可能有很多属性（比任何单个客户可能感兴趣的更多），甚至可能是子资源，并且客户可能会请求大量书籍，从而导致响应主体大于所需。

因此，我正在研究优化响应大小的方法。这个想法是为 API 客户端提供一些方法来指定响应中应包含多少细节。

我很想知道这个问题以前是如何解决的；哪种机制在实践中运行良好，哪些没有，哪种 API 设计特别 RESTful，哪些不是，等等。

我可以想到的几种方法是客户端如何为响应指定所需的详细程度：

  • 使用GET或HEAD HTTP 方法/动词。前者将返回所有细节，前者仅返回一个子集。

    这种方法只允许我们区分两个细节层次，所以它的用途有限。

  • 具有一个查询字符串参数，该参数指定（按名称）应在响应中返回哪些属性/属性。例如：

    GET /books?include=title,author,publisher,...,preview

    这提供了几乎无限的灵活性，但这种灵活性可能难以实际实现和处理（在客户端和服务器端）。

  • 使用不同的媒体类型（每个细节级别一个不同的媒体类型），通过Accept:标题选择。

    我真的不想走那条路。我不确定媒体类型是否适合此目的，而且世界可能无论如何都不需要更多自定义媒体类型。

  • 使用profile关系/媒体类型参数。这似乎好一点（不需要额外的媒体类型），但我仍然不确定媒体类型是否是选择响应的“内容”（内容）的正确方法。它们似乎更适合仅用于指定响应的“方式”（格式）。

  • 对于书籍集合 ( /books?publishedIn=1980s)，仅返回所有可用数据的一小部分，最重要的是href，每本书的 a 可以被查询以获取有关单本书的完整数据。

    这种方法至少有两个问题：

    1. 除了链接之外，集合响应中还包含哪些属性href？理想情况下，有足够的额外数据来满足大多数客户；除此以外...

    2. 客户将不得不执行许多额外的查询（每本书一个）来收集他们需要的所有数据。

可能有更多的策略来选择所需的详细程度。我有兴趣了解在实践中哪些方法行之有效，同时又不会对 RESTfulness 造成太大影响。

4

1 回答 1

1

我认为这主要取决于您希望为 API 客户端提供多少灵活性。

如果您知道数据的不同用途，您可能希望定义一些 API 可以返回的可用格式。

例如，使用这种结构：

 GET /books (with a default format if nothing is specified)
 GET /books/minimal 
 GET /books/full 
 GET /books/otherformat

请注意，如果您不想复制端点，也可以使用此 URL 结构：

GET /books?format=minimal

但是，无论哪种情况，这都会迫使您准确了解客户在任何给定时间需要或想要的数据。

我不会依赖媒体类型，因为这可能比其他更标准的使用 REST API 的方式更容易让用户感到困惑。

[编辑]

此外，如果您决定指定要返回的恶魔的整个列表并发现 GET 请求是不够的，您可以参考这篇文章以了解使用 POST 请求的替代方法

于 2016-08-05T18:20:45.417 回答