我正在创建一个由 API 提供支持的抽奖应用程序。层次结构相当简单。
- 客户
- 用户
- 抽奖
- 提交内容
客户可以拥有本质上是任何抽奖活动的管理员的用户。客户还可以进行多次抽奖。一个抽奖可以有多个提交。好吧，不复杂。
我感到困惑的是对 URL 结构的正确方法是什么。我已经阅读了互联网上的文档和最佳实践博客，但我仍然感到困惑。以下是我们目前的路线：
客户
POST /clients
GET /clients
GET /clients/:client_id
PUT /clients:client_id
用户
POST /users
GET /users
GET /users/:user_id
PUT /users/:user_id
DELETE /users/:user_id
抽奖
POST /sweepstakes
GET /sweepstakes
GET /sweepstakes/:sweepstakes_id
PUT /sweepstakes/:sweepstakes_id
DELETE /sweepstakes/:sweepstakes_id
提交
POST /submissions
GET /submissions
GET /submissions/:submission_id
PUT /submissions/:submission_id
DELETE /submissions/:submission_id
如您所见，我对每个资源都遵循了一个简单的 2 个 URL——我认为这是最佳实践。然后，您可以通过任何 GET 请求的查询参数（例如/submissions?sweepstakes_id={sweepstakes_id}、/sweepstakes?client_id={client_id}等）深入了解关联。
这对我来说当然是有道理的，但是我和我的同事争论不休，因为他正在使用 Backbone 来构建主要的前端应用程序。Backbone 声明他们立即支持 RESTful API 使用，但我的同事告诉我，Backbone 更喜欢表示该层次结构的 URL 结构。我当然认为这会导致 URL 结构混乱、冗长且整体令人困惑。理想情况下，我的同事希望看到以下 URL 结构：
GET /clients
GET /clients/users
GET /clients/sweepstakes
GET /clients/sweepstakes/submissions
注意：上面的路由也会有额外的路由通过 URL 中的额外资源 id 来补充单个资源（例如/clients/users/:user_id、/clients/sweepstakes/:sweepstakes_id/submissions等）。
我知道这是一个有点敏感的话题，但我很想听听对此的一些反馈。我投票给每个资源一个 2 个 URL，如果需要进行任何关联，可以通过使用 GET 或 POST 参数来完成。但我可能完全错了。