3

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

取而代之的是通用的“实体”示例，我将使用更普通的“文档”实体。

问题 1。

GET /document/?[query]

获取文档列表。问题是“文档”只有几十个属性，并且在许多情况下，客户端只关心少数几个（尤其是在此搜索中） - 响应的大小可能不同（最多 10 次），而且服务器查询可能会更快。另外，我不得不提到我们更喜欢无模式。

我发现了像

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

我觉得这很不适合 REST。

另一篇文章建议使用 Content-Types（实际上是接受，因为它是用于请求的），但是缺少示例并且仍然有复杂的感觉。就像是：

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

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

问题2。

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

编辑

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

编辑 2

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

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

4

1 回答 1

3

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

解决方案是选择不同的架构风格（RPC 通过减少消息的大小来最大化效率），或者影响您的客户想要 REST，因为它带来的质量优势：可扩展性、简单性、效率、可演化性和用户感知的性能.

于 2012-11-29T15:20:46.383 回答