Challenge Overview
Challenge Overview
Challenge Objectives
-
Java Rest API development using Spring Boot
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.
-
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 the service to support the frontend UI requirements
Technology Stack
-
Java 11
-
SpringBoot
-
MongoDB
-
JUnit
Code access
The base code is available in the forums and contains only the bare project structure. Project architecture and deployment instructions are available in the project wiki page (see the link in the forums)
Individual requirements
-
Calculation endpoints
This is a set of CRUDL endpoints for managing input data sets and the calculation results. Create/update endpoint will just call the calculation service and save the response in the database. Inputs to the create/update data endpoint are multipart form data: .las file and a string field “name”. Calculation service only has the json input endpoint so you will need to mock the multipart request endpoint in the calculation service. Response will still be in json.Get/list/delete endpoint will operate on the local data in the database - they won’t call the calculation service. Response will be the same as that of the calculation service (except that the data id is the id of the db record created by the service, not the id returned by the calculation service). List endpoint will support filtering and sorting by well name and date.
Data export endpoint
This endpoint will get take data id as path parameter, and call the data export endpoint from the calculations service and return the updated LAS file - this endpoint also does not exist in the calculations service so you will need to mock it.
-
Well name lookup endpoint
This endpoint will return unique well names and will have an optional name filter (well name LIKE filter*) from the calculation results collection.
NOTE: in this challenge we only have the Python backend, but it does not yet have the endpoints for multipart file upload and export, so you will need to create mock those for testing/verification.
For reference, this is the frontend that will use this service (marvel app link shared in the forums).
You will also need to create a document that maps the api calls to the UI - which endpoint to call for each of the UI screens and how to map the request and response data to the interface.
General requirements
-
Unit tests are required for all services (not the controllers) and tests should validate that the operation works correctly and the result is correct.
-
All database collection names should be prefixed with “API_NAME_SERVICE”
-
All configuration parameters should be extracted to the configuration file. Sensitive configuration parameters should be set from environment variables (DB URL, credentials, etc). All environment variables have to be prefixed with “API_NAME_SERVICE”
-
Please make sure your code is well-documented. 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.
What To Submit
-
All source code (git patch)
-
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
Best Practices & Comments(30% weightage)
· Does the submission follow standard best practices?
Score: 0-3
This section includes the code style, linter, patterns usage, code comments
Please make sure your code is well-documented. 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