Django REST API-媒体类型参数中的属性筛选器

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

我将使用更普通的“文档”实体，而不是一般的“实体”示例

问题1.

GET /document/?[query]

获取文档的列表。问题是“文档”有几十个属性，在许多情况下，客户机只关心几个属性（尤其是在本搜索中）——响应的大小可能相差几倍（最多10倍），服务器查询也可能更快。此外，我必须提到，我们更喜欢无模式

我找到了像这样的样品

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

我觉得很不舒服

另一篇文章建议使用内容类型（事实上是接受，因为它是用于请求的），但缺少示例，仍然有混合的感觉。比如：

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

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

问题2.

GET /document/?[query]

如果上面的解决方案或多或少是可接受的，我想知道在解析自定义媒体类型属性方面是否准备好了一些东西。从我在文档中看到的情况来看，媒体类型参数不是单独解析（或处理）的

编辑

一些附加信息：应用程序的很大一部分是OLTP（不可缓存）。架构是JSON服务器和静态文件，JS重客户端

编辑2

事实上，我发现一些观点认为搜索本质上是创建新的（不稳定的）资源（结果），所以POST方法更合适。这就消除了讨论中的问题。我对所创建的实体（结果）有一些问题，因为我不想坚持它，但我认为这不是强制性的。问题是在“位置”标题中放置什么（伪造URL、无位置标题或其他）？对我来说，唯一一致的行为就是我不想做的事情——search POST执行搜索，将结果存储在服务器端，并返回201及其链接。然而，这是不合理的持久性负载

---

关于浏览器测试，MIME类型的文本/html可能会提供一种用户友好的搜索形式。

体系结构样式会通知体系结构，这些体系结构会约束随后实施的设计。休息是一种建筑风格。您发现很难设计URI，不是因为实现选项有限，而是因为架构不匹配。您的客户“希望”通过减少消息的大小来最大限度地提高效率。但是您选择的体系结构样式（REST），这自然会导致更大的消息（因此资源更少）。如果您的体系结构没有使用缓存来最大限度地提高效率，那么它就偏离了REST样式（并可能形成一种新样式；Roy应该对这种非常常见的样式进行体系结构分析）

---

解决方案是选择不同的体系结构样式（RPC通过减少消息的大小来最大限度地提高效率），或者影响您的客户想要REST，因为它带来了：可伸缩性、简单性、效率、可进化性和用户感知的性能。

完全正确。我的问题没有提到缓存在大部分请求中都将被禁用。不过，它可能会在某些情况下启用，并且会考虑REST设计的其他好处。在特定情况下，对于媒体类型参数的使用仍然存在一个问题（在一般架构原则方面）。还有一个想法——媒体类型不应该影响缓存吗？如果它可以是JSON、XML或HTML，那么对同一URL的调用是如何被缓存的？为了保持属性集的可扩展性，您可以简单地考虑<代码> GET/DoC/[[Que]和Atts= AtTr1，AtTr2 < /Cord>。在Accept标头中指定属性意味着您无法使用通用浏览器测试该行为。关于媒体类型：如果要为同一资源返回不同媒体类型的表示，服务器需要发出

Vary:Accept

。它发出信号缓存以分别存储不同的表示。在这一点上，我不相信每个缓存实现都知道如何处理媒体类型参数。经过一些思考，在缓存方面，“GET/document/attr1，attr2../[query]”比“GET/document/？[query]&attrs=attr1，attr2”更好（假设每个客户端版本通常使用相同的顺序；据我所知，许多缓存代理忽略查询字符串）。缓存代理倾向于不缓存任何包含查询字符串的URI。我不知道有任何缓存基于URI，就好像它没有查询字符串组件一样。这将很快导致灾难并得到修复。经过一些研究，我真的认为通过体系结构解决性能问题更好（一些人在思考这个所谓的问题时失败了-），而不是使用“廉价”的技巧。这样的查询（如示例中所示）无论如何都不应该是可缓存的，而且应该返回链接列表，而不是直接值（同样从缓存的角度来看）。我认为这个答案是正确的：）