假设我有一个由学校，学生和班级组成的三级层次结构。
如果我将学生作为资源公开，我的问题是我是否应该总是将父母“学校”和孩子“班级”与该学生一起归还，或者是否应该有用户包含的parm来表明这一点。也许像＆amp; deep = True？
或者另一方面，如果用户得到学生，并且他想要学校，他必须在学校资源上进行GET，同样如果他想要学生正在学习的所有课程，他必须在类资源上做一个GET？
我正在努力让设计对未知的未来用户保持开放，而不仅仅是针对我们当前的需求进行编码。
谢谢，
Neal Walters
答案 0 :(得分：4)
如果您更多地考虑资源设计的方式，那么您可以更轻松地解决问题。没有理由不能在学生资源的表示中返回学校信息的子集，并且还会返回指向学校资源的完整表示的链接，以防用户希望看到更多信息。
我认为将REST接口更像是机器的用户界面而不是数据访问层是有用的。有了这种心态，在不同的资源表示中复制信息不是问题。
我知道有很多人试图将DAL视为DAL，但是当他们发现您无法通过RESTful接口进行交易时，他们会感到不安。
换句话说，设计你的API就像你设计一个网站一样（但没有任何漂亮的东西），然后构建一个可以抓取网站以获取所需信息的客户端。
答案 1 :(得分：1)
我认为添加查询参数以优化交付是合理的。我可能会使它更通用并使用include=<relation>。这可以扩展到所有类型。注意
您可以使用多个包含：.../student/<id>?include=school&include=student会将列表[school, student]分配给参数include。这也将允许一般模式，也可能对其他资源有用。
答案 2 :(得分：1)
我认为你应该避免将课程视为学生的子资源或属性。学术课程不仅仅是学生日程安排的时间段;它有一个教师，一个教学大纲等，所有这些都可能需要在某些时候进行编码。
在我看来，以下关系成立：
（如果您的要求包含此类信息，您也可以通过教师/教师轻松扩展这些内容。）
此外，上述每种资源类型除了它们之间的简单链接外，还有任意数量的属性。
鉴于此，我认为您需要一个类似于以下内容的URL结构：
http://example.com/lms/schools =＆gt;学校名单http://example.com/lms/schools/{school} =＆gt;关于一所学校的信息http://example.com/lms/schools/{school}/students =＆gt;学生名单http://example.com/lms/schools/{school}/students/{student} =＆gt;一个学生的信息http://example.com/lms/schools/{school}/students/{student}/courses =＆gt;课程列表（作为链接，而不是完整资源）学生已注册http://example.com/lms/schools/{school}/courses =＆gt;课程清单http://example.com/lms/schools/{school}/courses/{course} =＆gt;一门课程的信息http://example.com/lms/schools/{school}/courses/{course}/students =＆gt;在课程中注册的学生列表（作为链接，而非完整资源）