我想寻求一些关于设计REST/hipermedia API的建议，特别是关于使用django-est框架实现的建议。
我将使用一个更普通的"文档"实体来代替一般的"实体"示例。
问题1.
GET /document/?[query]
获取文档列表。问题是，"文档"只有几十个属性，在许多情况下，客户端只关心几个属性(尤其是在本次搜索中)——响应的大小可能会相差几次(最多10次)，而且服务器查询可能会更快。此外，我必须提到，我们更喜欢无模式。
我发现了像这样的样品
GET /document/attr1, attr2../?[query]
我觉得这很不舒服。
另一篇文章建议使用内容类型(事实上是Accept，因为它是用于请求的)，但缺少示例，仍然有复杂的感觉。类似于：
Accept: application/json; attrs="attr1,attr2"
我不确定这是否尊重HTTP的语义，也不确定媒体类型参数的使用是否合适(毕竟，我想要一个不同的资源表示——过滤掉一些属性)。
问题2.
如果以上或多或少是可访问的解决方案，我想知道django-rest中是否已经准备好了解析自定义媒体类型属性的内容。从我在文档中看到的情况来看，媒体类型参数没有单独解析(或处理)。
编辑
一些附加信息：应用程序的大部分是OLTP(带有将不可缓存)。架构是带有静态文件的JSON服务器，JS重客户端。
编辑2
事实上，我发现一些观点认为，搜索本质上是创建新的(不稳定的)资源(结果)，所以POST方法更合适。这就消除了正在讨论的问题。我对创建的实体(结果)有一些问题，因为我不想坚持它，但我认为这不是强制性的。问题是在"Location"头中放什么(伪造的URL，没有Location头或其他)？对我来说，唯一一致的行为正是我不想做的事情——searchPOST执行搜索，将结果存储在服务器端，并返回201和链接。然而，这是不合理的持久性负载。。。
关于浏览器测试，MIME类型text/html可以呈现用户友好的搜索形式。
体系结构样式通知体系结构，这些体系结构约束设计，然后实现设计。REST是一种体系结构风格。您发现很难设计URI，不是因为实现选项有限，而是因为体系结构不匹配。您的客户"希望"通过减少邮件大小来最大限度地提高效率。但是您选择的体系结构风格(REST)使用缓存来最大限度地提高效率，这自然会导致更大的消息(从而减少资源)。如果您的体系结构没有使用缓存来最大限度地提高效率，那么它就偏离了REST风格(并可能产生一种新的风格；Roy应该对这种非常常见的风格进行体系结构分析)。
解决方案是选择不同的体系结构风格(RPC通过减少消息大小来最大限度地提高效率)，或者影响您的客户端使用REST，因为它带来了质量优势：可扩展性、简单性、效率、可进化性和用户感知性能。