我正在设计一个API，我遇到了一个小问题： 当您应该能够通过ID或slug识别项目时，RESTful API的URL应该如何？
我可以想到三个选择：
GET /items/<id>
GET /items/<slug>
这要求slu and和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时重要的是什么？
答案 0 :(得分：10)
在我更喜欢第三种选择的三种中，看到这种语法并不罕见;例如Twitter的API的一部分允许该语法： https://dev.twitter.com/rest/reference/get/statuses/show/id
第四个选项是混合方法，您可以选择一个（例如，ID）作为单个项目的典型访问方法，但也允许基于slug的查询。 E.g：
GET /items/<id>
GET /items?slug=<slug>
GET /items?id=<id>
您的路由会明显将地图/项目/ ID转换为/ items？id =
可扩展到多个id / slugs，但仍符合将URI与基础数据模型匹配的REST范例。