-
Notifications
You must be signed in to change notification settings - Fork 0
restful api implementation
📑 Chapter summary
In this section you must implement a RESTful API. The minimum requirements are summarized in the Minimum Requirements section of the Project Work Assignment. If you do not meet the minimum requirements this section WILL NOT be evaluated.- Implement a RESTful API
- Write tests for the API
✔️ Chapter evaluation (max 20 points)
You can get a maximum of 20 points after completing this section. More detailed evaluation is provided in the evaluation sheet in Lovelace.📑 Content that must be included in the section
A list of all resourcess. Each resource should include its URL, a short description and supported methods. You should mark also which is the name of the class implementing the resource (if you have implemented such resource) Consider that you do not need to implement every resource you initially planned. The minimum requirements are summarized in the Minimum requirements section from the Project work assignment.✏️ List your resources here. You can use the table below for listing resources. You can also list unimplemented resources if you think they are worth mentioning
| Resource name | Resource url | Resource description | Supported Methods | Implemented |
|---|---|---|---|---|
| Resource Name 1 | ||||
| Resource Name 2 |
💻 TODO: SOFTWARE TO DELIVER IN THIS SECTION
The code repository must contain:- The source code for the RESTful API
- The external libraries that you have used
- We recommend to include a set of scripts to setup and run your server
- A database file or the necessary files and scripts to automatically populate your database.
- A README.md file containing:
- Dependencies (external libraries)
- How to setup the framework.
- How to populate and setup the database.
- How to setup (e.g. modifying any configuration files) and run your RESTful API.
- The URL to access your API (usually nameofapplication/api/version/)=> the path to your application.
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). In addition should be clear which is the code you have implemented yourself and which is the code that you have borrowed from other sources. Always provide a link to the original source. This includes links to the course material.
✏️ You do not need to write anything in this section, just complete the implementation.
💻 TODO: SOFTWARE TO DELIVER IN THIS SECTION
The code repository must contain:- The code to test your RESTful API (Functional test)
- The code of the test MUST be commented indicating what you are going to test in each test case.
- The test must include values that force error messages
- The external libraries that you have used
- We recommend to include a set of scripts to execute your tests.
- A database file or the necessary files and scripts to automatically populate your database.
- A README.md file containing:
- Dependencies (external libraries)
- Instructions on how to run the different tests for your application.
Remember that you MUST implement a functional testing suite. A detailed description of the input / output in the a REST client plugin.
In this section it is your responsibility that your API handles requests correctly. All of the supported methods for each resource should work. You also need to show that invalid requests are properly handled, and that the response codes are correct in each situation.
✏️ Most important part of this section is completing the implementation. Write down here a short reflection on which are the main errors you have solved thanks to the functional tests.
The repository contains functional test code written in Python using the pytest framework. Test cases are well-documented with comments to explain the purpose of each test scenario. Functional testing served as a critical tool for validating the correctness and reliability of the RESTful API implementation. Through rigorous testing and diligent error resolution, we were able to deliver a high-quality API that meets user expectations and industry standards.
-
Examples of tests include:
-
- Testing user registration with valid and invalid inputs.
-
- Testing authentication endpoints with correct and incorrect credentials.
-
- Testing CRUD operations on various resource endpoints.
-
- Testing edge cases such as boundary values and null inputs.
-
External Libraries Used:
-
- pytest: version 8.0.0
-
- requests: version 2.31.0
-
Dependencies:
-
- Python 3.9.6
-
- pytest 8.0.0
-
- requests 2.31.0
-
Functional testing revealed several key errors that were addressed:
-
- Input Validation Errors: Identified and fixed issues where the API failed to validate user inputs properly.
-
- Error Handling Flaws: Improved error handling logic to provide clear and informative error messages.
-
- Inconsistent Response Codes: Ensured consistent HTTP status codes across all API endpoints.
-
- Boundary Cases Handling: Implemented handling for edge cases and boundary conditions to enhance reliability.
Reflection on Main Errors Detected and Solved: Functional testing played a pivotal role in enhancing the robustness and reliability of the RESTful API implementation. By systematically testing various endpoints and scenarios, we were able to uncover and address several critical errors, including:
-
Input Validation Errors: For example, we discovered that the API did not validate email addresses properly during user registration, leading to potential security vulnerabilities. This issue was rectified by implementing robust input validation logic.
-
Error Handling Flaws: Through functional testing, we identified instances where the API returned generic error messages without providing actionable information to the client. By refining error handling mechanisms, we ensured that users receive meaningful error responses that aid in troubleshooting.
-
Inconsistent Response Codes: We observed inconsistencies in the response codes returned by the API for similar scenarios. By standardizing response codes across endpoints, we improved the predictability and consistency of the API's behavior, leading to a better user experience.
📑 Content that must be included in the section
Explain briefly how your API meets REST principles. Focus specially in these three principles: Addressability, Uniform interface, Statelessness. Provide examples (e.g. how does each HTTP method work in your API). Note that Connectedness will be addressed in more depth in Deadline 4.1. Addressability: Addressability in REST refers to the ability to address and uniquely identify resources using URIs (Uniform Resource Identifiers). In the API, each resource is represented by a unique URI. For example:
-
/users/represents the collection of users. -
/users/{user_id}represents a specific user identified by user_id. -
/products/represents the collection of products. -
/products/{product_id}represents a specific product identified by product_id. These URIs allow clients to address and interact with individual resources using standard HTTP methods.
2. Uniform Interface: The uniform interface in REST ensures that all components interact with resources in a consistent manner. HTTP methods such as GET, POST, PUT, DELETE are used consistently to perform operations on resources. Examples of how each HTTP method works in the API:
-
GET: Used to retrieve resource representations. For example, retrieving a list of users (GET
/users/) or a specific user (GET/users/{user_id}). -
POST: Used to create new resources. For example, creating a new user (POST /users/) or adding a product to favorites (POST
/products/{product_id}/favourite/add). -
PUT: Used to update existing resources. For example, updating user information (PUT
/users/{user_id}) or modifying a product (PUT/products/{product_id}). -
DELETE: Used to delete resources. For example, deleting a user (DELETE
/users/{user_id}) or removing a product from favorites (DELETE/products/{product_id}/favourite/remove).
3. Statelessness:
Statelessness in REST means that each request from a client to the server must contain all the information necessary to understand and process the request.
The server does not store any client state between requests. Each request is independent and self-contained.
In the API, each request contains all the required information for the server to process it.
For example, when a client sends a request to delete a user (DELETE /users/{user_id}), the request contains the user_id in the URI, and the server can process the request based solely on this information without relying on any previous interactions.
By adhering to these principles, the API provides a consistent, predictable, and scalable architecture for clients to interact with resources over HTTP.
📑 Details on extra features
This section lists the additional features that will be graded as part of the API but are not required. In addition to implementing the feature you are also asked to write a short description for each.📑 Fill this section if you used URL converters
Write a short rationale of how URL converters are used, including your thoughts on the possible trade-offs. Go through all URL parameters in your API and describe whether they use a converter, what property is used for converting, or why it's not using a converter.✏️ Write your text here
📑 Fill this section if you used JSON schema validation
Write a short description of your JSON schemas, including key decision making for choosing how to validate each field.✏️ Write your text here
📑 Fill this section if you implemented server side caching
Explain your caching decisions here. Include an explanation for every GET method in your API, explaining what is cached (or why it is not cached), and how long is it cached (and why). If you are using manual cache clearing, also explain when it happens.✏️ Write your text here
📑 Fill this section if you implemented authentication
Explain your authentication scheme here. Describe the authentication requirements for each resource in your API, and your reasoning for the decisions. In addition, provide a plan for how API keys will be distributed, even if the distribution is not currently implemented.✏️ Write your text here
| Task | Student | Estimated time |
|---|---|---|