I think you should avoid thinking of classes as a sub-resource or attribute of a student. An academic class is more than just a time slot on a student's schedule; it has an instructor, a syllabus, etc., all of which may need to be encoded at some point.
As I see it, the following relations hold:
- schools have zero or more students
- schools have zero or more classes
- students have zero or more classes
- classes have zero or more students
(You could also trivially extend these with teachers/instructors, if your requirements included such information.)
In addition, each of the above resource types will have any number of attributes beyond the simple links between them.
Given that, I would think you'd want a URL structure something like the following:
http://example.com/lms/schools
=> list of schoolshttp://example.com/lms/schools/{school}
=> info about one schoolhttp://example.com/lms/schools/{school}/students
=> list of studentshttp://example.com/lms/schools/{school}/students/{student}
=> info on one studenthttp://example.com/lms/schools/{school}/students/{student}/courses
=> list of courses (as links, not full resources) student is enrolled inhttp://example.com/lms/schools/{school}/courses
=> list of courseshttp://example.com/lms/schools/{school}/courses/{course}
=> info on one coursehttp://example.com/lms/schools/{school}/courses/{course}/students
=> list of students (as links, not full resources) enrolled in course
manpreet
Best Answer
2 years ago
Suppose I have a three level hierarchy consisting of school, students, and classes.
If I expose student as a resource, my question is whether I should always return the parent "school" and the children "classes" along with that student, or whether there should be parm that the user includes to indicate such. Perhaps something like &deep=True?
Or on the other hand, if a user gets a student, and he wants the school, he has to do a GET on the school resource, and likewise if he wants all the classes that a student is taking, he has to do a GET on the classes resource?
I'm trying to keep the design somewhat open for the unknown future user, rather than coding just for what our current requirements demand.
Thanks,
Neal Walters