django - REST API - 媒体类型参数中的属性过滤器

Question

我想寻求一些关于设计 REST/hipermedia API 的建议，特别是关于 django-rest 的实现。框架。

我将使用更普通的“文档”实体来代替通用的“实体”示例。

问题 1.

GET /document/?[query]

获取文档列表。问题是“文档”有几十个属性，在很多情况下，客户端只关心少数几个(尤其是在这个搜索中)——响应的大小可能会相差好几次(最多 10 次)，服务器也一样查询可能会更快。另外，我必须提到我们更喜欢无模式。

我找到了这样的样本

GET /document/attr1, attr2../?[query]

我发现它非常不符合 REST 风格。

另一篇文章建议使用 Content-Types(实际上是 Accept，因为它用于请求)，但是缺少示例并且仍然有复杂的感觉。像这样的东西:

Accept: application/json; attrs="attr1,attr2"

我不确定这是否尊重 HTTP 的语义，也不确定这样使用媒体类型参数是否合适(毕竟我想要一种不同的资源表示 - 过滤掉一些属性)。

问题 2.

如果以上是或多或少可以接受的解决方案，我想知道django-rest中是否有现成的东西？关于自定义媒体类型属性的解析。从我在他的文档中看到的，媒体类型参数没有单独解析(或处理)。

编辑

一些附加信息:大部分应用程序是 OLTP(不可缓存)。架构是带有静态文件的 JSON 服务器，JS 重客户端。

编辑2

实际上，我发现一些观点认为搜索本质上是创建新的(易变的)资源(结果)，因此 POST 方法更合适。这消除了正在讨论的问题。我对创建的实体(结果)有一些问题，因为我不想坚持它，但我认为这不是强制性的。问题是在“位置” header 中放入什么(虚假 URL，没有位置 header 或其他)？对我来说唯一一致的行为正是我不想做的 - 搜索 POST 执行搜索，将结果存储在服务器端并返回 201 及其链接。然而，这是不合理的持久性负载......

关于浏览器测试，MIME 类型 text/html 可能会呈现用户友好的搜索形式。

Answer 1

架构风格会告知架构，架构会限制随后实现的设计。 REST 是一种架构风格。您发现设计 URI 很困难，不是因为实现选项有限，而是因为体系结构不匹配。您的客户“希望”通过减少消息的大小来最大限度地提高效率。但是您选择的架构风格 (REST) uses caching to maximize efficiency ，这自然会导致更大的消息(因此资源更少)。如果您的架构不使用缓存来最大限度地提高效率，那么它就偏离了 REST 风格(并且可能会产生一种新的风格；Roy 应该对这种非常常见的风格进行架构分析)。

解决方案是要么选择不同的架构风格(RPC 通过减小消息的大小来最大化效率)，要么影响您的客户因为 the quality benefits 而需要 REST。它带来了:可扩展性、简单性、效率、可演化性和用户感知的性能。