33

我目前正在设计一个 API，但遇到了一个小问题： 当您应该能够通过 ID 或 slug 识别项目时，RESTful API 的 URL 应该是什么样子？

我可以想到三个选项：

GET /items/<id>
GET /items/<slug>

这就要求slug和ID是可区分的，本例中不一定给出。我想不出一个干净的解决方案来解决这个问题，除非你这样做：

GET /items/id/<id>
GET /items/slug/<slug>

这可以正常工作，但是这不是我想通过 slug 或 ID 识别项目的唯一地方，当一个人想要为其他操作实施相同的方法时，它很快就会变得非常难看。它只是不是很可扩展，这导致我们采用这种方法：

GET /items?id=<id>
GET /items?slug=<slug>

这似乎是一个很好的解决方案，但我不知道这是否是人们所期望的，因此可能会由于使用不当而导致令人沮丧的错误。此外，为这个实现路由也不是那么容易 - 或者说干净 - 实现路由。但是，它很容易扩展，并且看起来与获取多个项目的方法非常相似：

GET /items?ids=<id:1>,<id:2>,<id:3>
GET /items?slugs=<slug:1>,<slug:2>,<slug:3>

但这也有一个缺点：如果有人想用 ID 识别他想获取的一些项目，而用 slug 识别其他项目怎么办？混合这些标识符并不容易实现。

这些问题的最佳和最广泛接受的解决方案是什么？一般来说，在设计这样的 API 时，什么是重要的？

4

1 回答 1

16

在这三个选项中，我更喜欢第三种选项，这种语法并不少见。例如 Twitter 的部分 API 允许使用这种语法： https ://dev.twitter.com/rest/reference/get/statuses/show/id

第四个选项是混合方法，您可以选择一个（例如 ID）作为单个项目的典型访问方法，但也允许基于 slug 的查询。例如：

GET /items/<id>
GET /items?slug=<slug>
GET /items?id=<id>

您的路由将明显地将 /items/id 映射到 /items?id=

可扩展到多个 ids/slugs，但仍符合将 URI 与底层数据模型匹配的 REST 范式。

于 2012-04-04T19:55:29.240 回答