API consumption
📑 Chapter summary
In this section your group must design, implement and test a client application that uses the RESTful API implemented by you. If you utilize HTML and JavaScript, it is mandatory that the HTML is contained in static files. It means that your server cannot generate HTML dynamically (using PHP or JSP). All modifications made to the webpage must be done in the client side using javascript. Of course, you can use anchors () to load a new URL. Please, consider the Same Origin Policy" because it might cause problems to your client implementation. It is recommend to host the files in a local HTTP server and not directly in your file system. We will give you more instructions in Exercise 4.In addition, you must include an auxiliary service that interacts with your API (and possibly the client).
- Learn how to use APIs
- Implement a client that uses the project API
- Implement an auxiliary service that interacts with your API
✔️ Chapter evaluation (max 30 points)
You can get a maximum of 30 points after completing this section. You can check more detailed assessment criteria in the Lovelace return box for Deadline 5.📑 Content that must be included in the section
You must provide a description of the application. You must clarify which are the goals of the application and why a user would like to use this application. You must also state what is the functionality provided by the RESTful API used by this application.The application is a CLI client that interacts with our RESTful API. The goal of the application is to allow users to perform various operations already available on the StudentManager API, such as creating, updating, and deleting student, course, and assessment resources. Additionally, the application provides the option to generate an ID card for a specific student by making a request to our auxiliary service.
The CLI application presents options to the user for each loop cycle, executes the selected function, and presents the result to the user. The application keeps track of internal variables for state management and provides features such as always showing controls for the top nodes in the API (/api/students/, /api/courses, and /api/assessments), the ID card generation menu, and the option to exit the application. As an additional quality of life feature, the user may also decide whether they would like to follow the Location header for POST requests.
📑 Content that must be included in the section
Provide a use case diagram of your application. For each case, specify which is the API resource/s that cover the given functionality
📑 Content that must be included in the section
Draw a diagram of the client layout. Students can use any software they want to do the sketching. For more professional-like design, students can use any wireframing tool available in Internet. Some of them can be found from http://webdesignledger.com/tools/13-super-useful-ui-wireframe-tools. Pencil is free, open source and easy to use. Other options are Visio and Balsamiq (you need a license). You can also create the UI using a paper and a pencil and scan the resulting drawing.Since in our team there is no member with meaningful GUI design and development experience, we opted for a mostly CLI based application instead. Here, the options are displayed in the format [i] <description>, where i is the number the user has to type to choose that menu option. As an example, to generate an ID card, the user selects the "Generate ID Card" option, which will trigger a query to our auxiliary service. The application will then print the payload and status code of the sent request. The application does contain graphical elements, as it also opens a graphical window showing profile pictures and ID cards when they are generated.
Single menus are presented as such (for example, the Main Menu):
Current node: /api/
Please, choose one of the following actions:
[1] The collection of all students
[2] The collection of all courses
[3] The collection of all assessments
[4] Generate student's ID card
[5] Exit client
Enter number in range [1-5]:
📑 Content that must be included in the section
Draw the screen workflow of your client (which are the possible screens that you can access from one specific screen?)The screen workflow is kept consistent throughout the application, with options generated by the internal state related to the current node and the node the user came from. The diagram below includes all possible screens, but not all possible paths: from each screen, the user can navigate to the statically available options that are also presented in the Main Menu: Querying all Students, all Courses and all Assessments, Generating ID Card and Exiting the application. This is visualised as the actions pointing back to the options presented also in the Main Menu initially. The CLI menu is implemented as a loop, therefore at the end of each user action, the menu where the action was initiated is presented again. The arrows represent the usual path a user would take, but in fact users can navigate backwards as well, to the screen they came from, and the main menu options are always available to the user without navigating all the way back to the original node or navigating through a path until they reach the end of it.
When the client is launched, the Main Menu is presented to the user:
Current node: /api/
Please, choose one of the following actions:
[1] The collection of all students
[2] The collection of all courses
[3] The collection of all assessments
[4] Generate student's ID card
[5] Exit client
Enter number in range [1-5]:
If the user wants to query information about a student from the collection of all students (option 1 above, then appropriate option from the collection), they will be presented with the following prompt, and output for the picked student (in this case with student ID 1):
Please input the student ID: 1
student_id: 1
first_name: Draco
last_name: Malfoy
date_of_birth: 1980-06-05
ssn: 050680-6367
assessments:
1:
course_id: 1
student_id: 1
grade: 5
date: 1993-02-08
2:
course_id: 2
student_id: 1
grade: 4
date: 1993-02-17
Current node: /api/students/1/
Please, choose one of the following actions:
[1] self
[2] profile
[3] Modify a student
[4] Delete a student
[5] collection
[6] The collection of all assessments
[7] Get all the assessments of a student
[8] studman:propic
[9] The collection of all students
[10] The collection of all courses
[11] Generate student's ID card
[12] Exit client
Enter number in range [1-12]:
If the user picks option 8 from the menu above, the following window will be opened, displaying the user's profile picture:
💻 TODO: SOFTWARE TO DELIVER IN THIS SECTION
The code repository must contain:- The source code for the client application.
- External libraries. You can also report them in the README.md if the libraries are very big or need to be installed.
- The code for testing the application (if it exists).
- We recommend to include a set of scripts to run your application and tests (if they exist).
- A README.md file containing:
- Dependencies (external libraries)
- How to setup/install the client
- How to configure and run the client
- How to run the different tests of your client (if you have implemented unit testing)
📑 Content that must be included in the section
You must provide a description of the service. You must clarify which are the goals of the service and how it interacts with your API (and possibly the client). The service can be autonomous entity that does some automated work on the API (data cleaning, calculating composites etc.), or it can be commanded from the client interface to perform heavier tasks that would clog the API server itself (statistics generation, recommendation algorithms etc.).
The main goal of our auxiliary service is to generate and return a given student's ID card graphics that then would be printed on their card. This stylish student ID card comprises of the student's full name, date of birth, student ID number and their profile photo overlaid on a nice graphic. This auxiliary service is used by our client (the end user being the ID Card Provider) and it depends on our API to access all the required data to compile the card. Below is an example ID card as seen by the ID Card Provider when the client opens the generated image file in a preview window, allowing the user to view, adjust and export the file. This Auxiliary service also implements error handling and will return appropriate error messages reflecting the reason for why it failed to generate an ID card.
📑 Content that must be included in the section
Provide a diagram that shows how the service communicates with other parts in the ecosystem.
💻 TODO: SOFTWARE TO DELIVER IN THIS SECTION
The code repository must contain:- The source code for the auxiliary service.
- External libraries. You can also report them in the README.md if the libraries are very big or need to be installed.
- The code for testing the service (if it exists).
- We recommend to include a set of scripts to run your service and tests (if they exist).
- A README.md file containing:
- Dependencies (external libraries)
- How to setup/install the service
- How to configure and run the service
- How to run the different tests of your service (if you have implemented unit testing)
✏️ Do not need to write anything here. Implement your service
| Task | Student | Estimated time |
|---|---|---|
| Meetings | All | 1h |
| Implementation and documentation of ProfilePictureItem resource | Lorenzo Medici | 1.5h |
| Implementation of auxiliary service | Lorenzo Medici | 2h |
| Implementation of API client | Lorenzo Medici | 7h |
| Writing Wiki for Client | Daniel Szabo | 4h |
| Writing Wiki for Auxiliary Service | Daniel Szabo | 3h |