In database terminology primary key refers to the column in a table that's intended to be the primary way of identifying rows. Each table must have exactly one, and it needs to be unique. This is usually some kind of a unique identifier associated with objects presented by the table, or if such an identifier doesn't exist simply a running ID number (which is incremented automatically).
Deadline 4: API Documentation and Deployment¶
For this deadline you need to present your API's documentation. You also need to have all of your deliverable code available in the repository. Please make sure it is possible to install your project with your instructions, and view the API documentary live. If it is not possible to install your project due to it requiring installing anything outside a Python virtual environment, it is your responsibility to have your API running and API docs available on a live server.
Evaluation Criteria¶
| points | details | ||
|---|---|---|---|
| 1. Documentation | 9.0 | ||
![]() |
Documentation is valid | 1.0 | Validator for the documentation passes without any problems. E.g. if you paste your documentation into the Swagger Editor, it shows no errors/warnings. |
![]() |
Documentation structure | 1.0 | The documentation uses good structure to support its maintainability. Everything is only defined in one place. If either $parameters, $schemas, or $securityschemas are not in root:0.5. If no reference at all 0 points. |
![]() |
Documentation coverage | 1.5 | Every path is documented, and every available method for each path is also documented. 0.75 if there are some paths and methods missing or there is a minor mismatch between implementation and coverage |
![]() |
Response examples | 2.5 | All necessary examples are shown for each response body in the documentation. This includes different variations for resources that can have highly varying information. 1.5 if only one possibility is considered. 0.5 if there are multiple response bodies missing |
![]() |
Response codes | 2.0 | The documentation covers all response codes from the API, including error codes. Correct error codes are used for everything. 1.0 if there are a few missing error codes or the codes are using wrongly. 0.5 if error codes are not used at all. |
![]() |
Request bodies | 1.0 | Enough information about how to form request bodies is included in each request in the documentation. At minimum schema is included, examples are also included if needed. |
| API deployment. | 10.0 | ||
![]() |
Deployment in the cloud | 2.0 | The API is deployed in the cloud and accessible through a public IP. The development environment is explained in the report. |
![]() |
Monitor and control system | 1.0 | The deployment uses proper control and monitor systems (e.g. supervisor) |
![]() |
Architecture diagram | 2.0 | The diagram present clearly which are the different parts of the ecosystem, where the different services are deployed. It should contain the different component as well as their connection. Include econnection protocols. |
![]() |
Tools description | 1.5 | Include a list of all tools and frameworks utilized, and what is the role in the environment (e.g. docker, supervisor ...) |
![]() |
Use of Web Server and Application Server | 1.5 | The application is running in a proper Application Server (WSGI, Gunicorn, Tomcat). The chosen of the application server is justified.The application server is correctly configured. If not needed application server it should be correctly justified. (0.75p) Proper Web Server is used to serve static content (NGINX, Apache) and forward requests to application server. The server is correctly configured. Short justification of the selection in the report (0.75p) |
![]() |
VM/Docker | 2.0 | The API is running in its own VM or Docker environment. Configuration is correct and well documented. |
Return Box¶
To submit the deliverable, put a link to your repository or deadline 4 wiki page in the box.
Hints
Messages
