我正在创建一个由API驱动的抽奖活动应用程序。层次结构相当简单。
客户可以拥有基本上是任何抽奖活动管理员的用户。客户也可以有多次抽奖活动。单个抽奖活动可以有多个提交。好的，不复杂。
我感到困惑的是对URL结构的正确方法。我在互联网上阅读了文档和最佳实践博客，但我仍然感到困惑。以下是我们目前的路线：
客户 的
POST / clients
GET / clients
获取 / clients /：client_id
PUT / clients：client_id
用户 的
发布 /用户
获取 /用户
获取 / users /：user_id
PUT / users /：user_id
删除 / users /：user_id
的 SWEEPSTAKES 的
发布 /抽奖
GET /抽奖活动
GET /抽奖活动/：sweepstakes_id
PUT /抽奖活动/：sweepstakes_id
DELETE /抽奖活动/：sweepstakes_id
的提交的 的
发布 /提交
获取 /提交
获取 /提交/：submission_id
PUT /提交/：submission_id
删除 /提交/：submission_id
正如您所看到的，我每个资源都遵循一个简单的2个URL - 我认为这是最佳实践。然后，您可以通过任何GET请求上的查询参数钻取关联（例如 /提交？sweepstakes_id = {sweepstakes_id} ， / sweepstakes？client_id = {client_id} 等）
这当然对我有意义，但是我和我的同事处于关键状态，因为他正在使用Backbone来构建主要的前端应用程序。 Backbone表示他们支持RESTful API消费，但是我的同事告诉我Backbone更喜欢代表层次结构的URL结构。我当然认为这将导致混乱，冗长，整体混乱的URL结构。理想情况下，我的同事希望看到以下URL结构：
获取 / clients
获取 / clients / users
GET / clients / sweepstakes
获取 /客户/抽奖/提交
注意：上述路线还有其他路线可以通过URL中的额外资源ID来补充单个资源（例如 / clients / users /：user_id ， / clients / sweepstakes / ：sweepstakes_id / submissions 等。）。
我知道这有点敏感，但我很乐意听到一些反馈。我投票支持每个资源一个2个URL，如果需要进行任何关联，可以通过使用GET或POST参数来完成。但我可能完全错了。
答案 0 :(得分：6)
你是对的，这是一个有争议的话题。话虽如此，我发现Apigee的团伙在尝试充实api标准/定义时非常有帮助。他们并没有说一种方法是正确的，他们更倾向于根据他们的行业经验提出有根据的建议。
他们提供了一些很好的资源，并且有一些内容可以帮助您找到一个可以与您角落里的其他人一起捍卫您的意见的职位。
查看这个webinar ...这是相当基本的东西，但在api设计方面总是非常适合复习。
注意：我与Apigee没有任何关系，我只是认为他们已经做了一些很好的工作，试图为api设计定义一个标准。
〜祝你好运，我希望这会有所帮助
答案 1 :(得分：1)
我在official definition of REST中找不到任何表明分层URI是首选的东西，但我可能错过了一些东西。我对Backbone一无所知，但如果它需要这种结构，我想你必须这样做，但似乎没有任何理由为什么它会更好。但是，通常优选的是每个资源都有一个唯一的URI，而分层的URI似乎有几个。我知道你不能为你的同事说话，但他是否提出了为什么他的计划会有更好的功能的任何实际原因？