Challenge Overview
Challenge Objectives
-
Python Rest API development using Flask framework
Project Background
-
Our client has developed a specific method of calculating and visualizing various rock properties like Compressional velocity (Vc), Shear velocity (Vs), Young’s Modulus (E), Shear Modulus, Bulk Modulus (K), Poisson’s Ratio (PR), P-wave Modulus and Lambda.
-
The formulae of each of these will be provided in the forums.
-
We would need to maintain a configuration of the upper and lower limits of each of these values and return a flag if the final computed value falls in this range or not.
-
All the calculations are currently done manually today - our goal is to create an API to store and process the data, i.e. move the calculations to be done via a web-app.
Technology Stack
-
Python 3
-
Flask
-
Flask-Restplus
-
MongoDB
Code access
The base code is available in the forums. 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
-
Data Import endpoints
Current data import endpoint accepts json as the input to the calculations. The actual use case for this api is reading the input values from “.las” files - a specific data format used mainly in oil industry. In a previous challenge we have build a tool that can parse and write LAS files.
We need to add a new endpoint for data import (same path - POST /data) that accepts multipart form data: las file and a string field “name”, parses the LAS file and calculates the PVT values for each depth record in the ASCII section of the las file, and saves the results to database. Response will be the same json response returned by the existing data import endpoint (id, name, inputs, outputs, createdAt, updatedAt) -
LAS export endpoint
Create a new endpoint that takes data id as parameter and returns the LAS file that is exactly the same as the input file, but with the calculation results added as new columns in the ASCII section of the LAS file
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