我想就设计REST / hipermedia API寻求一些建议，特别是关于django-rest框架的实现。
相反，通用的“实体”示例，我将使用更普通的“文档”实体。
问题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方法更合适。这消除了讨论中的问题。我对创建的实体（结果）有一些问题，因为我不想坚持它，但我认为这不是强制性的。问题是在“位置”标题中放入什么（虚假URL，没有位置标题或其他）？对我来说唯一一致的行为正是我不想做的事情 - 搜索POST执行搜索，将结果存储在服务器端并返回201并链接到它。然而，这是不合理的持久性负载...
关于浏览器测试，MIME类型text / html可以呈现用户友好的搜索形式。
答案 0 :(得分：3)
架构风格告知架构，这些架构限制了随后实现的设计。 REST是一种架构风格。您发现很难设计URI，不是因为实现选项有限，而是因为架构不匹配。您的客户“希望”通过减少消息的大小来最大化效率。但是您选择的架构风格（REST）uses caching to maximize efficiency，自然会导致更大的消息（因此资源更少）。如果您的架构不使用缓存来最大限度地提高效率，那么它就会偏离REST风格（并且可能会创建一种新风格; Roy应该对这种非常常见的风格进行架构分析）。
解决方案是选择不同的架构风格（RPC通过减小消息的大小来最大化效率），或者影响客户端因为它带来的the quality benefits而需要REST：可伸缩性，简单性，效率，可演化性，和用户感知的表现。