-
Notifications
You must be signed in to change notification settings - Fork 0
analysis and reflection
📑 Chapter summary
In this section we would like that you reflect about the work you have done during the course.- Reflect about own learning
- Feedback on course instruction
✔️ Chapter evaluation (max 5 points)
You can get a maximum of 5 points after completing the Analysis and Reflection section. More information in Lovelace return box for Final deadline.📑 Content that must be included in the section
Explain how you would improve your RESTful API and your client application. Try to develop the ideas, and explain why each improvement is needed✏️ The first important and security related change we would apply would be to change how the resources are identified in the URLs. In the current implementation, the database IDs are used to identify students or courses, but this could lead to breaches and exploits by malicious actors by exposing the internal implementation of our API and database. Currently, courses could be identified by their code, which is by definition unique. This would require a modest amount of changes to our API. On the other hand, we currently don't have a valid field to replace the identifiers for students, as the only unique field other than the database ID is their SSN, which shouldn't be used in URLs for clear security and privacy reasons. Some kind of random identifier or combination of surname and other details could be used, with a thought on minimizing privacy risks. In any case, changing the ID method for both resources would involve changing how assessments are identified in our API, since they internally store the pair or student and course ID, and this is reflected in their URLs.
Another change we would consider applying would be to simplify the code related to the assessment collections. Having a single endpoint for adding assessments is convenient, but the fact that the collection of assessments for a student or a course are implemented as two different resources produces a large amount of repeated code. With some careful consideration, it should be feasible to create only one resource class handling both the collections as distinct endpoints, with some if-else blocks responsible for the differences in URLs and hypermedia controls.
In our API, the profile pictures are only implemented as a mock up to let us test our auxiliary service. This means that the related resource class returns the same static picture for any student. The next logical step would be to properly implement the management of each student's profile picture, by letting users upload and/or access the profile picture for a given student ID. This would also involve some planning as to how to store the pictures, and how to treat them when students are deleted, or whether to make them mandatory in POST/PUT requests, or (if they were optional) what to return to users accessing them.
Finally, the client was implemented as a CLI application, since nobody in the group had enough experience with GUIs to implement one for this project. In the future, a GUI could be implemented to make the client more user-friendly and aesthetically pleasing. As far as the current client implementation is concerned, the code isn't written in a very clear way and is probably not too maintainable as all the members of the team were extremely busy before the last deadline, so the final polishing and code cleaning phase was skipped altogether.
📑 Content that must be included in the section
Discuss in this section the things that you would have done differently if you started the project after this course ends.✏️ The fact that profile pictures were only partially implemented came from us overlooking their design and implementation, giving for granted that they would be stored as files in the server, and not included in the database. Since the course followed a clear database -> API -> Hypermedia workflow, it was very easy to forget about the additional requirement for our auxiliary service, and only be able to partially implement them at the end of the projcet. If we were to start this project now we would consider more carefully all the data types and requirements our API has, and implement from the start mechanisms to allow us to have them finished properly by the end of the project.
Additionally, the security considerations about identification and exposure of the internal structure will be remembered by the team mebers for future projects and professional experience.
📑 Content that must be included in the section
Comment where you encountered the main difficulties while doing your project work. Discuss about the easiest/most difficult parts of the project. Provide convincing statements.✏️ As nobody was experienced in professional-level coding in Python, there was a steep learning curve regarding code quality and, espectially, testing of the database and API as this was the first time anybody in the team used the pytest framework.
The API implementation also provided some challenges due to the good amount of things to pay attention to (e.g. content type, request schema, itneration with the database, correct status codes, etc... ).
On the other hand, the Resource Oriented Architecture and the REST principles were easy to grasp conceptually, and abide by during the design and implementation. Similarly, Hypermedias were made quite clear in the relative lecture and exercise material once they were properly explained, and a couple of examples were read and analyzed by each member. Their implementation wasn't extremely challenging once they were understood and our API's hypermedia diagram was defined.
📑 Content that must be included in the section
Make sincere comments about the course. How this course could be improved? What should be changed? What should not be changed?✏️ The course was overall well managed and provided all necessary material (and additional resources) to allow us to be able to learn all the topics and implement all necessary components with no previous at all in implementing APIs ( and having no idea about what REST principles and Hypermedia were). The auto-corrected exercises were appreciated as they gave concrete feedback, and were useful for ironing our doubts and mistakes in our code.
The suggestion we would like to make is related to the in-person Q&A sessions. Especially for the first couple of deadlines they were scheduled quite late in the time span between the two deadlines, with only a week and a half after them before the next deadline. At that point in time, hopefully all the exercises would have been already completed since work had to be started already on the project. We think this might be the reason for the poor participation to the sessions, despite the extra point awarded to participants. Overall, support was mostly received through Discord, which we think was very helpful with the direct communication it provides.
| Task | Student | Estimated time |
|---|---|---|
| Meeting, discussion and writing of wiki page content | All | 1.5h |