python - 具有多个强制参数的 RESTful URI 的最佳设计是什么？

Question

我想看看是否有更多经验丰富的 Web 服务老手可以评论在我需要强制参数的地方设计 RESTful URI 的最佳方法。例如，我想设计一个请求数据的 URI:

example.com/request/distribution

但是，根据我的理解，该方法是应该在更高级别返回更多数据，而如果应用更具体的 URI 关键字，将返回更详细的数据，但就我而言，我需要至少 3 个值才能实现.这 3 个值将是日期值、帐户值和专有分发代码值。例如:

example.com/request/distribution?acct=123&date=20030102&distcode=1A;1B;1C

这是否被视为“RESTful”URL 或是否有更好的方法更有意义？非常感谢任何输入。

顺便说一句，Python 是首选语言。谢谢!

Answer 1

根据定义，URI 本身不能是“非 REST 风格的”，因为 URI 规范是由 REST 架构风格指导的。您使用 URI 的方式可能违反 REST 风格:

1. 不遵守“客户端-服务器”约束；例如，通过使用WebSockets 实现服务器推送。
2. 不遵循“资源标识”约束；例如，使用 URI 的一部分来指定控制数据或资源元数据，而不是坚持识别资源，或者通过 URI 以外的某种机制(如 session 状态或其他带外机制)来识别资源。
3. 不遵循“通过表示操纵资源”的约束；例如，通过使用 URI 的查询字符串部分来传输状态。
4. 不遵循“ self 描述消息”约束；例如，使用 HTTP GET 修改状态，或传输 Content-Type 为“text/html”的 JSON。
5. 不遵循“超媒体作为应用程序状态引擎”的约束；例如，不提供要遵循的用户代理超链接，而是假设它将使用带外知识构建它们。
6. 不遵循“分层系统”约束，要求客户端了解服务器工作原理的内部细节(特别是要求客户端在请求中提供这些细节)。

以上都不一定是糟糕的选择。它们可能是您系统的最佳选择，因为它们促进了某些体系结构属性(例如效率或安全性)。它们只是不是 REST 风格的一部分。

您的资源由多个强制性段标识这一事实是 URI 设计的重要组成部分。正如 Anton 指出的那样，example.com/request/distribution?acct=123&date=20030102&distcode=1A;1B;1C 和 example.com/accounts/123/distributions 之间的选择/20030102/1A;1B;1C 纯粹是数据设计之一，而不是 URI 层本身的问题。例如，响应前者的 PUT、POST 或 DELETE 请求并没有错。未能跟踪任何一个链接的客户端将被视为损坏。期望通过超媒体响应以外的某种方式将其中任何一个提供给客户端的系统将被视为“非 RESTful”。