Quartz Energy - Unit Converter API

Challenge Objectives

 

• Python Rest API development using Flask framework

• Implement CRUDL endpoints for units and groups

• Implement unit conversion endpoints

 

Project Background

• Our client has developed a unit converter tool that we want to port to Python and expose as an API

• All the conversions and unit definitions are currently in an Excel workbook - our goal is to create an API to manage unit definitions, and unit conversions

• In this challenge, we’ll implement all the crud and conversion endpoints

 

Technology Stack

 

• Python 3

• Flask

• Flask-Restplus

• MongoDB

• Pint - unit conversion library

 

Code access

 

The base code is available in the forums and contains only the bare project structure.

 

Individual requirements

 

We will be using Pint unit conversion library and expand on its unit definition capabilities. The library is using a text file for storing the unit definitions, and allows loading custom definition files(see ureg.load_definitions). The idea is to use the default definition file to use the existing units, and to have another definitions file that would be updated by the API endpoints. We will support add/update/delete/list operations for units and groups. Each unit will be defined by the Pint requirements (name, definition (formula), list of aliases, group).

It is up to you to decide how to store the new units and groups - you can update the new Pint definitions file directly, or store all the information in a JSON file (for easier management) and create the Pint definitions file on demand (when initializing the Pint library and converting the units).

Here are the endpoints that the API should support

1. CRUDL endpoints for units
   All units will be identified by their name (ex “second”) - it is a unique identifier. Attributes of a unit are name, formula, aliases, and group. For the units listing endpoint you will need to get the list of units from the pint library (you need to research how to do this) and for each unit return the name, formula, aliases, and group.
   When creating a new unit, the API should try to add it to Pint and in case any error occurs, return the error to the caller.

2. Convert endpoint
   This endpoint will accept 3 parameters (JSON body): from, to, amount.
   Successful conversions should be logged to a database (Mongo) - last N conversions should be stored for each unit group (N=10 by default).

3. Conversion log endpoints
   This simple endpoint will return last conversions for all the conversion groups

General requirements

 

• Unit tests are required for all endpoints.

• All endpoints should be annotated with Swagger annotations and swagger UI should be served by the API.

• All configuration parameters should be extracted to a common settings module. Sensitive configuration parameters should be set from environment variables (DB URL, credentials, etc).

• Please make sure your code is well-documented. Use the following style guides Google Python Style Guide, Python Style Guide, and Docstring Conventions. Code linter is required. Please make sure it is well-engineered but not over-engineered (YAGNI and KISS) solution. We're looking for well-structured and tested code. Well-structured code follows good design principles like the SOLID principles and well-tested code has comprehensive unit tests.

• The code should be implemented using Python3 only.

 

What To Submit

 

• All source code

• Deployment guide

• Postman collection containing sample calls for all endpoints (success/failure)

• Verification guide - how to set up the environment, start the API, and verification screenshots

• The unit tests coverage report

 

Scoring Methodology

 

Contest Specification Requirements(60% weightage)

 

·       Have all major specification requirements been met?

Score: 0-9

Major requirements are:

·       all endpoints are implemented correctly and return the correct data and codes, etc,

·       all DB models are defined and contain correct attributes and data types

·       Unit tests - minimum coverage 80%

                       Have all major specification requirements been met?

Score: 0-3

Minor requirements are:

 

·       Postman collection

·       Swagger annotations

 

Best Practices & Comments(30% weightage)

 

·       Does the submission follow standard best practices?

Score: 0-3

This section includes the PEP-8 code style, linter, patterns usage, code comments

Please make sure your code is well-documented. Use the following style guides Google Python Style Guide, Python Style Guide, and Docstring Conventions. Code linter is required. Please make sure it is well-engineered but not over-engineered (YAGNI and KISS) solution. We're looking for well-structured and tested code. Well-structured code follows good design principles like the SOLID principles and well-tested code has comprehensive unit tests.

 

Deployment and verification guide (10% weightage)

 

·       Does the deployment guide contain everything needed to successfully configure and deploy the API?

Score: 0-3

 

Final Submission Guidelines

see above