Week 3 - Developing Course APIs

I left last week with the idea of implementing the next two calls.

GET /api/students/[student_id]/courses  
GET /api/instructors/[instructor_id]/courses  

The former would retrive a list courses that a student is enrolled in and the latter would get the list of courses an instructor teaches.

The emphasis in these two calls was to re-use the SQL queries for all calls that returned a list of courses. This was best accomplished by adding the following where clauses for each of the .

WHERE ... AND ('%s' = 'garbage_value' OR title like '%%s%') AND ...;  

If a certain variable (like title) wasn't present in the URL parameters, it is assigned a garbage value. Therefore, the first part of the clause is true and this part doesn't affect the whole query in general. If the variable is present, the first part of the query is false and the second part determines if it's true overall.

After all that, we are having second thoughts about the complexity of the query. I will try an alternative version where I develop the WHERE clause using PHP and check which one is faster.

Additional API calls were implemented for students and instructors as follows. I believe they are self explanatory.

GET /api/students/[student_id]/courses/[course_id]  
GET /api/students/[student_id]/courses?title=[title]&category_id=[category_id]&primary_language=[primary_language]

GET /api/instructors/[instructor_id]/courses/[course_id]  
GET /api/instructors/[instructor_id]/courses?title=[title]&category_id=[category_id]&primary_language=[primary_language]

Another part that I completed in the week was to develop the APIs for course categories (except PUT pending some discussions with my mentor). (Note that these course categories are different from question categories and I would need to create an API for them later in the summer.)

This week also saw some changes in the structure of the code. Some of the logic that I kept in core/api_functions.php was moved to a shared directory. Core now contains functions related to the core functioning of the API (like logging and token management.)

I also changed the function print_error to print_message. The first argument specifies if it's an error or a success message to be printed. Chaning the function also involved adding a logging functionality to messages. (Remember, as of last week, only successes were being logged?)