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

Question

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

取而代之的是一般的'实体'的例子，我会用一个更平凡的'文档'实体。

问题1：

GET /document/?[query] 

得到的文件清单。问题在于“文档”只有几十个属性，在很多情况下，客户端只会关注少数几个（特别是在此次搜索中） - 响应的大小可能会有几个（最多10次）不等，而且服务器查询可能会更快。另外，我不得不提到，我们更喜欢无模式。

我发现样品如

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

我觉得这完全是非REST-FUL。

另一篇文章是建议使用内容类型（实际上接受，因为它是请求），但是例子丢失了，仍然有混合的感觉。喜欢的东西：

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

我不知道这是否是尊重HTTP的语义，并且如果这种使用的媒体类型参数是合适的（毕竟我要资源的不同表现 - 与某些属性过滤掉）。

问题2：

如果上面或多或少aceptable的解决方案，我不知道是否有什么准备django-rest关于自定义介质类型的属性解析。从我在文档中可以看到的信息来看，媒体类型参数不是单独解析（或处理）的。

编辑

一些额外的信息：应用程序的很大一部分是OLTP（带不会缓存）。架构是带有静态文件的JSON服务器，JS重型客户端。

编辑2

其实，我发现了一些意见，在他们的自然搜索是新的（挥发性）资源（结果）创作，所以POST方法是比较合适的。这消除了讨论中的问题。我对创建的实体（结果）有一些问题，因为我不想坚持它，但我认为这不是强制性的。问题是要在“位置”标题中添加什么内容（伪造URL，没有位置标题或其他内容）？对我来说唯一一致的行为正是我不想做的 - 搜索POST执行搜索，将结果存储在服务器端并返回201并链接到它。然而，这是没有道理的持久负载...

关于浏览器测试，MIME类型text/html可能会提供一个用户友好的搜索表单。

Answer 1

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

解决方案是选择不同的架构风格（RPC通过减少消息的大小来最大限度地提高效率），或者影响客户端需要REST，因为它带来了：可伸缩性，简单性，效率，可演化性和用户友好性，感知的表现。