9

我正在寻找是否有更多经验丰富的 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 是首选语言。谢谢！

4

4 回答 4

5

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

  1. 不遵循“客户端-服务器”约束；例如，通过使用 WebSockets 实现服务器推送。
  2. 不遵循“资源识别”约束；例如，使用 URI 的一部分来指定控制数据或资源元数据，而不是坚持标识资源，或者通过 URI 以外的某种机制（如会话状态或其他带外机制）来标识资源。
  3. 不遵循“通过表征操纵资源”的约束；例如，通过使用 URI 的查询字符串部分来传输状态。
  4. 不遵循“自我描述信息”的约束；例如，使用 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 请求没有任何问题。未能点击任何一个链接的客户将被视为已损坏。期望通过超媒体响应以外的其他方式向客户端提供其中任何一个的系统将被视为“unRESTful”。

于 2012-07-09T00:59:02.713 回答
3

最好先根据资源而不是 URI 创建 RESTful API。它更多地与您的数据设计有关，而不是与您选择的语言有关。

例如，您有一个分发资源。您想在基于 Web 的 API 中表示它，因此它需要具有适当的唯一资源标识符 (URI)。它应该简单、易读且不太可能更改。这将是一个不错的例子：

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

在将更多内容和层次结构放入 URI 之前请三思。

随着数据模型或身份验证方案的发展，您不希望更改 URI。更改 URI对您和使用您的 API 的开发人员来说既不酷又痛苦。因此，如果您需要将身份验证传递给后端，您可能应该使用 GET 参数或 HTTP 标头（例如，AWS S3 API允许两者）。

将过多的 GET 参数（例如 ）放入 GET 参数（例如http://example.com/api/distribution/?id=<some_unique_id>）可能看起来是个坏主意，但 IMO 并不重要[0] — 只要您保持 API 文档可访问且保持最新。

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

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

于 2012-07-08T23:07:53.850 回答
0

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

example.com/distribution/123/20030102/1A;1B;1C
于 2012-07-08T21:56:19.040 回答
-1

当您考虑 RESTful 时，大多数时候您还应该考虑 CRUD。

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

GET-Request 可以显示某些内容（CRUD 中的 R）。

但是您认为 CUD-Parts 的 URL 是什么？

于 2012-07-08T21:29:55.500 回答