API URL结构

Question

我正在创建一个由API驱动的抽奖活动应用程序.层次结构相当简单.

1. 客户端
2. 用户
3. 抽奖活动
4. 提交

客户可以拥有基本上是任何抽奖活动管理员的用户.客户也可以有多次抽奖活动.单个抽奖活动可以有多个提交.好的,并不复杂.

我感到困惑的地方是对URL结构的正确方法.我在互联网上阅读了文档和最佳实践博客,但我仍然感到困惑.以下是我们目前的路线:

CLIENTS

POST/clients
GET/clients
GET/clients /:client_id
PUT/clients:client_id

USERS

POST/users
GET/users
GET/users /:user_id
PUT/users /:user_id
DELETE/users /:user_id

抽奖

POST /抽奖
GET /抽奖
GET /抽奖/:sweepstakes_id
PUT /抽奖/:sweepstakes_id
DELETE /抽奖/:sweepstakes_id

提交

POST /提交
GET /提交
GET /提交/:submission_id
PUT /提交/:submission_id
DELETE/submissions /:submission_id

正如您所看到的,我每个资源都遵循一个简单的2个URL - 我认为这是最佳实践.然后,您可以通过查询参数在任何GET请求上钻取关联(例如/提交？sweepstakes_id = {sweepstakes_id},/ sweepstakes？client_id = {client_id}等).

这当然对我来说很有意义,但是我的同事和我在一起,因为他正在使用Backbone来构建主要的前端应用程序.Backbone表示他们支持RESTful API消费,但我的同事告诉我Backbone更喜欢代表层次结构的URL结构.我当然认为这将导致混乱,冗长,整体混乱的URL结构.理想情况下,我的同事希望看到以下URL结构:

GET /客户
GET /客户/用户
GET /客户/抽奖
GET /客户/抽奖/提交

注意:上述路由还有其他路由来通过URL中的附加资源ID来补充单个资源(例如/ clients/users /:user_id,/ clients/sweepstakes /:sweepstakes_id/submissions等).

我知道这有点敏感,但我很想听到一些反馈.我投票支持每个资源一个2个URL,如果需要进行任何关联,可以通过使用GET或POST参数来完成.但我可能完全错了.

Answer 1

你是对的,这是一个有争议的话题.话虽这么说,我发现Apigee的团伙在试图充实 api标准/定义时非常有帮助.他们并没有说一种方法是正确的,他们更倾向于根据他们的行业经验提出有根据的建议.

它们提供了一些很好的资源,并且有一些内容可以帮助您找到一个可以与您角落里的其他人一起捍卫您的意见的位置.

看看这个网络研讨会 ......这是相当基本的东西,但总是很适合api设计的复习.

注意:我与Apigee没有任何关系,我只是认为他们已经做了一些很好的工作,试图为api设计定义一个标准.

祝你好运,我希望这会有所帮助