带有集合的类的 RESTful url？答案

【问题标题】：RESTful url of classes with collections?带有集合的类的 RESTful url？
【发布时间】：2013-01-20 17:06:56
【问题描述】：

我正在实现一个 web 应用程序并希望遵守 RESTfull 设计标准，我的问题是。

给定一个带有集合的类。

人{ id :: 整数名称::字符串朋友 :: 人物集合 }

实现 Person 类接口的“最”正确方法是什么：

example.com/REST/persons -> [... {id: '2', name: 'Pete', friends: [1,4,6]} ... ]
example.com/REST/persons/2 -> {id: '2', name: 'Pete', friends: [1,4,6]}

使用persons类的一些搜索功能可以在哪里查找朋友？

或

example.com/REST/persons -> [... {id: '2', name: 'Pete'} ... ]
example.com/REST/persons/2 -> {id: '2', name: 'Pete'}
example.com/REST/persons/2/friends -> [{id: '1', name: 'Joann'}, 
                                       {id: '4', name: 'Jim'},
                                       {id: '6', name: 'Charlie'}]

集合中的元素在 person 实例中作为字段查找。

我已经看到了这两个方面的实施，但我想遵守标准。

第三种方式刚刚涌向我。

example.com/REST/persons/2 -> {id     : '2', 
                               name   : 'Pete', 
                               friends: [example.com/REST/person/1,
                                         example.com/REST/person/4,
                                         example.com/REST/person/6]}

因此使接口事件更加 RESTfull —— 客户端现在可以遍历整个接口，而无需了解任何关于实现的信息。

我希望那里有一些输入。

【问题讨论】：

您打算使用什么技术来实现您的 REST API？这个选择可以为你做出这个决定。
另外，您的问题标题具有误导性，看起来您正在寻找 URL 格式而不是实际实现。
@Zepplock：我改了标题
@RaySaltrelli：接口不应该独立于实现，我认为这就是拥有 RESTfull 接口的全部意义......
理论上是的。但是，如果没有一些妥协，理论通常不会转化为实践。例如，如果您为 REST API 选择 ASP.NET Web API，那么实现选项 2 将相当困难，因为它需要将纯粹风格的 REST 与 RPC 风格的 REST 混合，而 Web API 不喜欢这样。

标签： web-services rest web-applications

【解决方案1】：

拥有example.com/REST/persons/{person-id}/friends/{friends-id} 是正确的方法。 REST 本身不强制执行任何 URL 组合规则，但这是大多数人所做的。

基本上你有一个资源Person 和一个子资源Friend 具有多对多关系。

【讨论】：

朋友们，朋友们呢？这不是一个非常不干净和冗长的界面吗？
这个想法是，通过这个 URL，你可以很容易地看到关系。对于每个Person，您可以获得朋友列表。无需将这些资源链接到 2 层以上的深度。
其他人刚刚告诉我，正确的方法可能是在顶部对象中提供一个 url 列表......因此使对资源的访问更加 RESTfull
这实际上是一种更 RESTful 的方式，但在我看来不太实用。这将导致许多新的请求。仅当您出于性能原因可以可靠地缓存它们时才使用它。