-
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 implemented resources. 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. Do not forget to include in the README.md file which is the path to access to your application remotely.✏️ 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 |
|---|---|---|---|---|
| RecipeCollection | /api/recipes/ | Collection of Recipes | get/post | yes |
| RecipeItem | /api/recipes/{recipe}/ | Single recipe in a collection | get/put/delete | yes |
| UserRecipe | /api/{user}/{recipe}/ | a Single recipe of a certain user | get/put/delete | yes |
| UserRecipeCollection | /api/{user}/ | Collection of recipes of a single user | get/post | yes |
| RecipeIngredients | /api/recipeingredients/ | Proxy to connect ingredients to recipe | get/post | yes |
| Ingredients | /api/ingredients/ | used ingredients on recipes | get/post | yes |
💻 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.
✏️ 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.
✏️ You do not need to write anything in this section, just complete the implementation.
📑 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, and Statelessness. Provide examples (e.g. how does each HTTP method work in your API). Note that Connectedness will be addressed in Deadline 4.✏️
Our API has 6 resources that are used: RecipeCollection, RecipeItem, UserRecipe, UserRecipeCollection, RecipeIngredients and Ingredients and all of them are addressed with own URI.
Given principles are Uniform interface, Statelessness and Addressability. Uniform interface and Addressability principle is followed with the use of standard URI so all resourced are identified. Our resources are all unique as can be seen from the resource table. They all have a unique identifier. Our API also uses standard HTTP so all communication and actions of the resources are based on http methods get/put/post/delete. Responses from HTTP requests always have a status and a body.
The API conforms to Statelessness to level 3, as it implements Hypermedia controls, which return information of a request with unique links to requested content. For example, when requesting information of a User, the request contains information of the Users other records, such as recipes. And also one singular recipe of certain user can be retrieved with unique link to content.
📑 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.Our application uses URL converters to transform an URL part of the User and Recipe to useful python objects, which can be used better within the API without needing to strictly input all the info directly to the URL.
First converter is the Recipe converter, which gets the name of the Recipe from the URL and searches this Recipe by name from the database, and returns a Recipe object for the needing API routes. This is useful since this way a recipe can be searched with and id, while the user only needs to input a name.
Second converter is the User converter, which as well is searched from the database with the name given in the URL. This as well gives the routes access to the User object, which can be useful, since it is not viable to for example input an user email directly to the URL if needed.
The converters are useful in our use cases, and do not offer any serious trade offs. Of course this can be counter active if some parts of the system a user id is needed rather than the name, or vise versa, this could be confusing for the user when reading the documentation. Basically when changing the data format needed for the converter.
📑 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.✏️ Our project utilizes schema validation. This is used to check the correctness of the posted information. The schemas contain required fields for each of the used database models that need to be inputted when creating a such object into the database. This way there wont be errors trying to insert some incomplete information to the database, but only containing the minimum required info, which rest can be inserted later.
📑 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 |
|---|---|---|