Quartz Energy - PVT Properties API

Challenge Objectives

 

• Python Rest API development using Flask framework

• Implement CRUDL endpoints for data import and calculations

Project Background

• Our client has developed a specific method of calculating specific oil properties

• All the calculations are currently in an Excel workbook - our goal is to create an API to store and process the data, i.e. move the calculations from Excel into the codebase.

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

 

Technology Stack

 

• Python 3

• Flask

• Flask-Restplus

• MongoDB

 

Code access

 

The base code is available in the forums and contains only the bare project structure. The calculation specification document and the sample Excel file are available in the forums. We recommend reading these files before moving on to the next section of the challenge spec.

 

Individual requirements

 

1. Data Store CRUDL endpoints
   This is a set of CRUDL endpoints for managing input data sets and the calculation results. Inputs will be in JSON format (list of input fields required for calculation is available in the calculations spec). Note that the POST /data endpoint will accept an array of inputs (so the user can call the API with multiple sets of inputs defined in the calculations spec). Apart from calculation inputs, we will store helper fields “name”, and sampleNumber. Each record should be saved to database and createdAt, updatedAt endpoints should be maintained. Create and update endpoints will recalculate the results, store them to database (along with the input data) and return them in the response. List endpoint will support pagination, filtering and sorting by name and date.
   Calculations of each output value are implemented in excel as macros and we will port them to Python in this challenge - all the details are in the calculations spec. Calculated values should match with those in Excel.

 

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 endpoint routes should be prefixed with “API_NAME_”

• All database collection names should be prefixed with “API_NAME_”

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

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

• Use matrix operations with numpy/pandas where possible

 

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