有多个强制参数的restfuluri的最佳设计是什么？

Question

我想看看是否有更多经验丰富的web服务老手能够对如何在需要强制参数的情况下设计restfuluri的最佳方法发表意见。例如，我想设计一个请求数据的URI：

example.com/request/distribution

然而，根据我的理解，这种方法是在更高的级别返回更多的数据，而如果应用更具体的URI关键字，则会返回更详细的数据，但在我的例子中，我需要至少3个值才能实现这一点。这3个值将是日期值、帐户值和专有发行代码值。例如：

^{pr2}$

这被认为是一个“RESTful”URL，还是有更好的方法更有意义？非常感谢您的任何意见。在

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

Answer 1

顾名思义，URI不能“毫无保留”，因为URI规范是由REST架构风格指导的。如何使用URI会违反REST样式：

1. 不遵循“客户机-服务器”约束；例如，通过使用WebSocket实现服务器推送。在
2. 不遵循“标识资源”约束；例如，使用URI的一部分来指定控制数据或资源元数据，而不是坚持标识资源，或者通过URI以外的机制（如会话状态或其他带外机制）标识资源。在
3. 不遵循“通过表示来操纵资源”约束；例如，使用URI的querystring部分来传输状态。在
4. 不遵循“自描述性消息”约束；例如，使用httpget修改状态，或传输内容类型为“text/html”的JSON。在
5. 不遵循“超媒体作为应用程序状态的引擎”约束；例如，不提供要遵循的用户代理超链接，而是假设它将使用带外知识构造它们。在
6. 不遵循“分层系统”约束，要求客户机了解服务器工作原理的内部细节（特别是要求客户机在请求中提供）。在

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

您的资源由多个强制段标识这一事实是URI设计的重要组成部分。正如Anton所指出的，在example.com/request/distribution?acct=123&date=20030102&distcode=1A;1B;1C和{}之间的选择纯粹是数据设计的一个问题，而不是URI层本身的问题。例如，对前者的PUT、POST或DELETE请求作出响应没有什么错。一个客户端如果没有跟踪到其中任何一个的链接，将被视为断开。如果一个系统希望通过超媒体响应以外的其他方式向客户提供其中一个，则该系统将被视为“无反应”。在

Answer 2

RESTful的方法是将数据表示为资源，而不是请求的参数：

example.com/distribution/123/20030102/1A;1B;1C

Answer 3

最好先根据资源而不是uri创建restfulapi。它与你的数据设计有关，而不是你选择的语言。在

例如，你有一个分销资源。您希望在基于web的API中表示它，因此它需要有一个适当的惟一资源标识符（URI）。它应该简单易读，不太可能改变。这是个不错的例子：

http://example.com/api/distribution/<some_unique_id>

在将更多内容和层次结构放入uri之前，请三思而后行。在

您不希望随着数据模型或身份验证方案的发展而更改uri。更改uri对您和使用API的开发人员来说是uncool的痛苦。因此，如果您需要将身份验证传递到后端，您可能应该使用GET参数或HTTP头（例如，aws3api，allows both）。在

对GET参数（例如，http://example.com/api/distribution/?id=<some_unique_id>）投入太多似乎是个坏主意，但在我看来，这并不重要[0]——只要你保持API文档的可访问性和最新性。在

[0]更新：至少对于只读API。对于crudapi，正如@daniel所指出的，当您拥有如上面第一个示例中那样的端点时，它会更加方便。这样，您就可以很好地使用HTTP方法，方法是为/api/distribution/<id>上的单个资源启用GET、PUT、DELETE，并将POST to /api/distribution来创建新的发行版。在

在研究答案时，发现了一个关于restfulapi的很好的演示：Designing HTTP Interfaces and RESTful Web Services。在