Quartz Energy - XRD Services - API Specification Challenge

Challenge Objectives

 

• Design API specification (Swagger)

• Design database entity models

 

Project Background

 

• Our client has developed a specific method of analyzing geological data from soil samples which involves converting Weight percent mineralogy data to volume percent and integrating the calculation with porosity and organic carbon data.

• 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 create an API specification and database models.

• Follow-up challenges will focus on implementing the api (Python), calculation optimization (Python) and testing (manual and automated)

 

Technology Stack

 

• Swagger Open API Specification

• ERD

• MongoDB

• Excel

 

Resources

 

In the challenge forums you’ll find 3 documents:
 

• Sample Excel file with input and output data

• Data overview presentation

• Calculations specification document

 

We recommend reading these files before moving on to the next section of the challenge spec.

 

Individual requirements

1. API Specification

Api should support the following features:

• Minerals catalogue - CRUD endpoints for managing list of known minerals and their properties: name, chemical formula, expected range of densities (upper, lower) and flag to mark if the mineral is counted towards clay density

• Data import endpoint - Specifying . This endpoint should save the data to data store and create a unique id to reference it later. Note that list of minerals for each sample is different and should reference the mineral catalogue. Input csv file will contain only original weight percentage data (from tab zero). Input file should be saved to disk storage, and database record should contain file name, number of records in the input file, and kerogen weight percentage. All endpoints will provide response in JSON format.

• Calculation endpoints - one endpoint for each step of the calculations (each tab). Endpoint parameter will take the input data for a sample (data from tab zero, estimated kerogen carbon content - tab 2) Response should contain all the data from the respective sheet in the sample excel file. Note that minerals list should include only minerals used in the sample, not all the minerals from the catalogue.
  
   

2. ER Diagram
   Create an Entity relationship diagram that will map the application data to database tables. Only minerals catalogue will be stored. Calculation endpoints will calculate data on the fly and won’t store it to database.

 

General for all requirements

 

Use camelCase for all JSON data attribute names, TitleCase for table names and camelCase for columns. You can assume we’ll use MongoDB as the backing data store, so use sql server data types for table columns.

 

What To Submit

 

Submit a Swagger API specification

Submit an ER diagram

 

Scoring Methodology

 

Contest Specification Requirements(60% weightage)

 

• Have all major specification requirements been met?

Score: 0-9

Major requirements are:

• all endpoints are defined in the swagger and contain all the input/output parameters, response codes, etc,

• all db models are defined and contain correct attributes and data types

 

Best Practices & Comments(40% weightage)

 

• Does the submission follow standard best practices?

Score: 0-3

This section includes the mentioned naming requirements, swagger models definition, etc

Final Submission Guidelines

Submit a Swagger API specification

Submit an ER diagram