Nea*_*ers 5 rest resources web-services
假设我有一个由学校、学生和班级组成的三级层次结构。
如果我将学生暴露为资源，我的问题是我是否应该始终与该学生一起返回父“学校”和子“班级”，或者是否应该有用户包含的参数来指示这一点。也许像 &deep=True 这样的东西？
或者另一方面，如果用户获取一个学生，并且他想要学校，他必须对学校资源执行 GET，同样，如果他想要学生正在学习的所有课程，他必须执行 GET在课程资源上？
我试图让设计对未知的未来用户保持一定的开放性，而不是仅仅根据我们当前的需求进行编码。
谢谢，
尼尔·沃尔特斯
如果您更多地以考虑 UI 设计的方式来考虑资源设计，那么问题就会变得更容易。您没有理由不能在学生资源的表示中返回学校信息的子集，并且如果用户希望查看更多信息，也可以返回学校资源的完整表示的链接。
我发现将 REST 接口视为机器的用户界面而不是数据访问层很有用。有了这种心态，在不同的资源表示中重复信息就不是问题了。
我知道有很多人试图将 REST 视为 DAL，但当他们发现无法通过 RESTful 接口进行事务时，他们也会感到沮丧。
换句话说，像设计网站一样设计 API（但没有任何漂亮的东西），然后构建一个可以抓取网站以获取所需信息的客户端。
我认为你应该避免将课程视为学生的子资源或属性。学术课程不仅仅是学生日程上的一个时间段；它也是学生的一个时间段。它有一个讲师、一个教学大纲等，所有这些都可能需要在某个时候进行编码。
在我看来，存在以下关系：
（如果您的要求包含此类信息，您也可以简单地向教师/讲师扩展这些信息。）
此外，上述每种资源类型除了它们之间的简单链接之外还具有任意数量的属性。
鉴于此，我认为您需要一个如下所示的 URL 结构：
http://example.com/lms/schools=> 学校列表http://example.com/lms/schools/{school}=> 关于一所学校的信息http://example.com/lms/schools/{school}/students=> 学生名单http://example.com/lms/schools/{school}/students/{student}=> 一名学生的信息http://example.com/lms/schools/{school}/students/{student}/courses=>学生注册的课程列表（作为链接，而不是完整资源）http://example.com/lms/schools/{school}/courses=> 课程列表http://example.com/lms/schools/{school}/courses/{course}=> 一门课程的信息http://example.com/lms/schools/{school}/courses/{course}/students=>注册课程的学生列表（作为链接，而不是完整资源）| 归档时间： |
|
| 查看次数： |
630 次 |
| 最近记录： |