'api/SomeEntity/ForOtherEntity/{otherEntityId}' 会破坏 REST 吗？答案

【问题标题】：Does 'api/SomeEntity/ForOtherEntity/{otherEntityId}' break REST?'api/SomeEntity/ForOtherEntity/{otherEntityId}' 会破坏 REST 吗？
【发布时间】：2015-06-09 18:56:17
【问题描述】：

以 facebook 用户拥有一组照片为例，如果我正在为照片设计一个 RESTful API，这些将有照片本身的 GET/POST/PUT/DELETE 端点，是破坏 REST 还是设计通过用户 ID 获取的模式？例如

GET Photos/ //gets all photos
GET Photos/12345 //gets photos with photo.id=12345
GET Photos/ForUser/27 //gets photos for user with user.id=27

这是否违反了 REST API 的设计原则？更重要的是，添加与 API 主题不同的实体相关的方法会带来哪些实际负面影响？

【问题讨论】：

标签： rest asp.net-web-api

【解决方案1】：

不，您的 URL 不违反 REST 的任何原则 - 原因很简单，REST 不关心 URL 结构。

我建议阅读一两本 http://www.infoq.com/articles/rest-reading-list 提到的“REST”书籍，以开始使用 REST。

如果您进一步阅读 REST 的原始定义，那么您将找不到有关 URL 结构的任何信息（例如，请参阅 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm）。

【讨论】：

【解决方案2】：

根据 Rest 标准，父实体应首先出现在 URI 中，然后是标识符，然后是该实体中的任何资源。可以参考Rest API Design modelling article by Thoughtworks

以下是按照 REST 标准的正确 URI。

GET Photos/ //gets all photos
GET Photo/12345 //gets photos with photo.id=12345
GET User/27/Photos //gets photos for user with user.id=27

【讨论】：

GET User/27/Photos 存在于 UserEndpoint 而不是 PhotoEndpoint 上有意义吗？
User 和 Photos 实体之间将定义一对多的关系。如果从模型对象的角度考虑，照片的集合必须在用户实体中声明。采用这种方法，我将建议使用这种 URI 模式。但正如 Jorn Wildt 所说，您并没有违反任何原则，所以这完全取决于您的选择。