Currently, we have one centralized grade endpoint that handles all types of grade queries based on a provided subject, course number, and/or professor.
For example, a current grade request might look something like this:
GET /grades?subject_prefix=CS&course_number=1337
For the sake of backwards-compatibility and supporting mixed queries, it would be best to leave the current grades endpoint in place. That being said, it could be considerably more convenient for the following endpoints to also be created:
Course-specific grades: GET /course/{courseId}/grades
Section-specific grades: GET /section/{sectionId}/grades
Professor-specific grades: GET /professor/{professorId}/grades
Ideally these endpoints will be able to share as much internal logic with the current /grades endpoint as possible so as to keep things uncluttered.
Currently, we have one centralized grade endpoint that handles all types of grade queries based on a provided subject, course number, and/or professor.
For example, a current grade request might look something like this:
GET /grades?subject_prefix=CS&course_number=1337
For the sake of backwards-compatibility and supporting mixed queries, it would be best to leave the current grades endpoint in place. That being said, it could be considerably more convenient for the following endpoints to also be created:
GET /course/{courseId}/grades
GET /section/{sectionId}/grades
GET /professor/{professorId}/grades
Ideally these endpoints will be able to share as much internal logic with the current
/grades
endpoint as possible so as to keep things uncluttered.