REST 把数据视为资源，通过 URI 对资源进行唯一的标识。
一般是这样的：http://example*com/customers/1234
或者是这样的：http://example*com/orders/2007/10/776654
在具体项目中，如果某个 API 关联很深，就可能会导致 URI 会很长，举个不恰当的例子：中国有很多 University ;
关系如下：
University has_many colleges
College has_many clazzs
Clazz has_many students
Student has_many elective_courses
ElectiveCourse has_many homeworks
Homework has_many scores
如果我要获取 XX 大学 XX 学院 XX 学生 XX 课程 XX 作业的成绩中第 N 次成绩，URI 好像是这样的：
/universities/:univerity_id/colleges/:college_id/clazzs/:clazz_id/students/:student_id/elective_coruses/:elective_course_id/homeworks/:homework_id/scores/:score_id，
如果在逻辑中会判断所有参数的有效性（比如 university 是否存在，某个 college_id 是否在某个 univerty 存在...) , 这种情况在复杂逻辑关联中会出现。
虽然不是处女座，但是看到这么长的 URI 好纠结。话说稍旧的 Swagger 也会让这个 URI 不换行。
不知道各位在实践中是如何处理类似问题的，希望提出意见。谢谢。
Option 1:
/scores/:score_id?univerty_id=1&college_id=2&clazz_id=3&student_id=4& ... &homework_id=10
2.7.1 Limits to Nesting http://guides.rubyonrails.org/routing.html#limits-to-nesting
Resources should never be nested more than 1 level deep.
直接/scores/:score_id 就好了。
我从另一个角度给你解释为什么不需要带上上层的 id：
假设你给另外系统提供 API 接口，获取 score 信息，正常情况是 /scores/:score_id，对方有 score id 就可以 CRUD 了。而你要是把嵌套信息也加到 url 里，那么对方请求你一次 API 需要知道你整个数据库的结构了，才能给你提供 univerty_id college_id clazz_id student_id homework_id，这就是耦合。因为你自己的页面一般查完 score 就查 college 等信息你没发觉而已。
如果 URL 中是 slug 还有点意义，纯 ID 的话 
可是试着组织特定 ID 格式，如：1-2-3-4 找到 score 验证其他 ID.
提示：
如果需要这么严格的验证的话，最好在 score 中把 univerty_id, college_id, clazz_id, student_id, homework_id 都放在表里，一级级向上/下关联很耗资源。
建议善用主键。
主键总是唯一的，直接单层就好了。
嵌套资源本意是用作语义优化，但是你带上这么长的 url，根本就优化不了语义了。
article/1/comment/2 这种能直接看出 comment 与 article 的依赖关系，一个评论是基于一篇文章的。
但是 university/2/college/25/clazz/843/student/8928305/score/2333855 这种 url，score 跟 university 跟 college 都完全没有关系的，根本没必要放在一个 url 里了。
你这种情况，最多最多，/student/:id/score/:id 就足够了。
1、老师 F 属于 大学 A -> 学院 B -> 班级 C
2、学生 G 也属于大学 A -> 学院 B -> 班级 C
你的问题：老师 F 能否修改 学生 G 的成绩？
也不需要通过你那么长的 url 完成判断 1、老师和学生添加关联关系 或 2、老师和学生是否在同一班级（任课/学习）确认
你没有交待清楚班级（或上级）、老师、学生之间的关系 如果考虑到老师跨院系甚至跨学校任教的情况，仅利用那大长串 URL 来判断，不知道你遇到过麻烦的地方没有 这可能是没有必要的（具体还得根据你的业务需求定）
