API consumption - shanz007/IceHockeyTrackerAPI GitHub Wiki

Important information for Deadline 5

‼️  This chapter should be completed by Deadline 5 (see course information at Lovelace)


📑  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).

CHAPTER GOALS

  • 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.

RESTful Client

Client application description

Overview

📑  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.

✏️ Write here your application description

The client application serves as a robust platform designed to streamline the management of ice hockey teams and facilitate efficient decision-making processes for sports administrators, coaches, managers, and players. With a user-friendly interface and comprehensive functionality, this application aims to optimize team strategies, enhance player performance, and improve overall sports administration efficiency. Also by leveraging the RESTful API provided by the IceHockeyTracker system, this client empowers users to effectively manage premier league data and make informed decisions to drive success on and off the ice.

This application is for ice hockey teams and managers. It helps them with tasks like managing teams, scheduling matches, and tracking player performance. Users can sign up, log in, and manage their accounts with different roles like player, coach, manager, or admin. The application provides access to tournament stats, match results, and player rankings. It also has a dashboard with graphs and reports for analyzing data and making decisions. Also, the application implements robust authentication and authorization mechanisms to ensure secure access to sensitive data, with each user assigned a unique API key during onboarding and access to specific functionalities based on user roles and permissions.


Functional requirements

📑  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

✏️ Draw your diagram here including a discussion of use cases

Use case diagram (1)

The use case diagram shows the interactions between actors and the system in the IceHockeyTrackerAPI environment. The primary actors identified include "Administrator," "Player," "Coach," and "Manager," each representing distinct user roles within the system. The diagram illustrates various use cases that these actors can perform.

For instance, the "Administrator" can manage roles, users.

Players, on the other hand, have limited functionalities such as authenticating.

Coaches and Managers share similar capabilities with the Administrator extending to managing teams, match schedules, match feedback, tournament statistics, rank bases, and user ranks but with restricted access to certain functionalities like managing roles.


Client design

GUI layout

📑  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.

✏️ Add your diagrams here

Login Page:

IMG_1308 2

Dashboard Page:

IMG_1308 3

List Page:

IMG_1308 5

Details Page:

IMG_1308 4


Screen workflow

📑  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?)

✏️ Add your diagrams here

When logged in as an Administrator:

IMG_1311

When logged in as a Manager:

IMG_1309

When logged in as a Player:

IMG_1312

Client implementation

💻     TODO: SOFTWARE TO DELIVER IN THIS SECTION The code repository must contain:
  1. The source code for the client application. 
  2. External libraries. You can also report them in the README.md if the libraries are very big or need to be installed.
  3. The code for testing the application (if it exists).
  4. We recommend to include a set of scripts to run your application and tests (if they exist).
  5. 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)
NOTE: Your code MUST be clearly documented. For each public method/function you must provide: a short description of the method, input parameters, output parameters, exceptions (when the application can fail and how to handle such fail). Check Exercise 4 for examples on how to document the code. addition, should be clear which is the code you have implemented yourself and which is the code that you have borrowed from other sources.

✏️ Implement your client and include a few screenshots of the final version of the client to show that meets the requirements


Auxiliary Service

Service description

Overview

📑  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.).

✏️ Write your description here

The Auxiliary Service is an important component of the IceHockeyTracker ecosystem, designed to handle automated tasks that complement the functionalities of the IceHockeyTrackerAPI. This service acts as an autonomous entity responsible for performing various backend tasks

In the IceHockeyTracker API system, we calculate player grades upon invoking an auxiliary service. All the coaches' feedback and rankings are utilized to calculate a grade for the players.

Grading is generated based on the player's user ranking point scheme, where coaches rank the players based on the matches they have played during the tournament. The userRank base is utilized to record grading rules.

The administrators are given full privileges to add, update, and delete any rank-based rules. Coaches are allowed to add and edit their rankings in the system.

At the end, users can generate a player report highlighting the matches played along with the grading, which would be useful for providing insights to sports administration to make future decisions regarding improvements, contract stages, and so on.

When sports management clicks on the player report on the GUI, a REST API call will be sent to the IceHockeyTracker API system.

Functional requirements

📑  Content that must be included in the section Provide a diagram that shows how the service communicates with other parts in the ecosystem.

✏️ Put your diagram here

hPF1ReCm38RlF8NLUr-WXwcLfcWzH9fQ-W1Uy5RKaR34LDhRpuawb43HTkWX0i9dy_cFs0P6pqFtMQ5Xv-4Ko5UzRBMcxT4ohE8EQBJuGHt9nf7yjJMq0WnmqiSItXjwSUP2txL7kVZTwxueaEUoe2RibhhNq-uQsPoNQ3sb5L7p9XPB1KeAgZJT-YbEie7Tm6UXMeDCCO_sAZTfI5c94bemOoY8dhkGhHhAmAoXJBg10tqD


Auxiliary service implementation

💻     TODO: SOFTWARE TO DELIVER IN THIS SECTION The code repository must contain:
  1. The source code for the auxiliary service. 
  2. External libraries. You can also report them in the README.md if the libraries are very big or need to be installed.
  3. The code for testing the service (if it exists).
  4. We recommend to include a set of scripts to run your service and tests (if they exist).
  5. 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)
NOTE: Your code MUST be clearly documented. For each public method/function you must provide: a short description of the method, input parameters, output parameters, exceptions (when the application can fail and how to handle such fail). Check Exercise 4 for examples on how to document the code. Should be clear which is the code you have implemented yourself and which is the code that you have borrowed from other sources.

✏️ Do not need to write anything here. Implement your service


Resources allocation

Task Student Estimated time
Meetings All 8h
API Consumption,implementation,Documentation Shanaka Badde Liyanage Don 22h
API Consumption,implementation,Documentation Emmanuel Ikwunna 14h
API Consumption,implementation,Documentation Md Mobusshar Islam 15h
⚠️ **GitHub.com Fallback** ⚠️