Challenge Overview
App environment:
- OpenAPI 3.0
Basic requirements for this challenge:
- Designing OpenAPI 3.0 Mock Service for the Thor Early Alert Tool Application based on requirements below
- Submit OpenAPI 3.0 file
Project Background
The Early Alert Tool (EAT) is a data store for all of the Codes and Standards which Thor needs to follow when developing products. As codes and standards change or improve, the divisions within Thor (specifically the division leaders and product managers) need to be alerted of these changes.
The division leaders document the issues which arise from any of these changes along with and need to track details on the action plans for those issues. A number of different users will be using the application. There could be codes & standards committee representatives who notify other key point people (product managers or division leaders) of the changes.
The main goal of the application is three-fold:
1. Highlight the standards which have been identified by the business divisions as important
2. Notify people within divisions of standards changes (email functionality)
3. Track the internal corporate action plans issues related to standards changes
General Requirements
- App spec should written in OpenAPI 3.0
- Follow the attached ERD for the database schemas: https://www.lucidchart.com/publicSegments/view/5345b6fa-1a47-498d-a6e6-66dafc46b17a/image.jpeg
- We just get winning submission from previous Docker Setup: https://drive.google.com/open?id=1-wuH2gyw9PxTCcG4uzkLDhMXWgjpnl8r
- Winning Storyboard Design: https://drive.google.com/open?id=14usuK-pnbZvywBf0NT5nek1y2L0YQEZEPz0Ra4_4ntE
- You can follow complete data type definitions from the ddl.sql
- The requests and responses should properly list all fields.
- For responses, you should cover all the cases, not just 200 status code, like 404. '400': Bad Request, '401': Unauthorized, '403': Forbidden, '409': Conflict
- Summary & Descriptions should be properly written for APIs, request input and responses etc
- Create some sample body request for each API paths
- Support Create, Update, Delete, Read, Read all data for all endpoints
- We need specific search endpoints to pull data from Standard with some qualifiers
- All endpoints must be protected and JWT passed in the request header must be used for authentication.
- be capable of setting bounds (constraints) on data entry (so that any new data being entered is consistent in format) – the data format definitions will be defined by the codes and standards group. (see “CnS Data type Definitions.xlsx” file)
- Suggest best practices endpoints format for the actual API implementations
Individual Requirements
Swagger doc should contain definitions for the following collections:
1). Search
Allow users to query the entire dataset on any word or number (text) contained in the database support incomplete word/number queries. As an example if someone is searching for all “complete” items ; the user can enter “comp” and have everything with those letters come up.
- Need to return the standards records with related data
- allow the use of search qualifiers such as “and”, “not”, and “or”
- allows user to search an email address
- filtering capabilities
-- ex1: find all contacts and committee participants for a Division or for a standard;
-- ex2: identify all Standards within a specific division)
2). Standard
- Need Support all CRUD endpoints
3). CnSIssue
- Need Support all CRUD endpoints
4). Standard Division
- Need Support all CRUD endpoints
5). Standard Division Contact
- Need Support all CRUD endpoints
6). Organization
- Need Support all CRUD endpoints
7). Division
- Need Support all CRUD endpoints
8). SubDivision
- Need Support all CRUD endpoints
9). Product Line
- Need Support all CRUD endpoints
10). Product Line Contact
- Need Support all CRUD endpoints
11). User
- Create 3 user roles:
- Administrator: Access to all application data, user management (add/edit all users), and access to modify data
- Data Manager: Access to add, edit, modify standards data and C&S Issue data
- Standard User: Access to view and search standards data, send notifications, and create and edit user’s own C&S issue data
- Need Support all CRUD endpoints
12). History
- Need Support all CRUD endpoints
General Filtering
The parameters should be returned in the response with the total count of matching records as well, It is preferred if the default values are configurable.
General Pagination
We need to add pagination when user scrolling the page, these endpoint should have the following parameters :
- offset (default 0)
- limit (default 15)
The parameters should be returned in the response with the total count of matching records as well, It is preferred if the default values are configurable.
We’ll follow a subjective scorecard (1-10) for this challenge. The submissions will be evaluated on the basis of
- Completeness of Swagger file with respect to challenge requirements
- Adherence to best practices for designing REST API
- Accuracy of screen to API mapping
- Sample data on each endpoints.
What To Submit
- Swagger file
- Feel free to include any other document(s) that you think will help coders better understand how to implement the API
- OpenAPI 3.0
Basic requirements for this challenge:
- Designing OpenAPI 3.0 Mock Service for the Thor Early Alert Tool Application based on requirements below
- Submit OpenAPI 3.0 file
Project Background
The Early Alert Tool (EAT) is a data store for all of the Codes and Standards which Thor needs to follow when developing products. As codes and standards change or improve, the divisions within Thor (specifically the division leaders and product managers) need to be alerted of these changes.
The division leaders document the issues which arise from any of these changes along with and need to track details on the action plans for those issues. A number of different users will be using the application. There could be codes & standards committee representatives who notify other key point people (product managers or division leaders) of the changes.
The main goal of the application is three-fold:
1. Highlight the standards which have been identified by the business divisions as important
2. Notify people within divisions of standards changes (email functionality)
3. Track the internal corporate action plans issues related to standards changes
General Requirements
- App spec should written in OpenAPI 3.0
- Follow the attached ERD for the database schemas: https://www.lucidchart.com/publicSegments/view/5345b6fa-1a47-498d-a6e6-66dafc46b17a/image.jpeg
- We just get winning submission from previous Docker Setup: https://drive.google.com/open?id=1-wuH2gyw9PxTCcG4uzkLDhMXWgjpnl8r
- Winning Storyboard Design: https://drive.google.com/open?id=14usuK-pnbZvywBf0NT5nek1y2L0YQEZEPz0Ra4_4ntE
- You can follow complete data type definitions from the ddl.sql
- The requests and responses should properly list all fields.
- For responses, you should cover all the cases, not just 200 status code, like 404. '400': Bad Request, '401': Unauthorized, '403': Forbidden, '409': Conflict
- Summary & Descriptions should be properly written for APIs, request input and responses etc
- Create some sample body request for each API paths
- Support Create, Update, Delete, Read, Read all data for all endpoints
- We need specific search endpoints to pull data from Standard with some qualifiers
- All endpoints must be protected and JWT passed in the request header must be used for authentication.
- be capable of setting bounds (constraints) on data entry (so that any new data being entered is consistent in format) – the data format definitions will be defined by the codes and standards group. (see “CnS Data type Definitions.xlsx” file)
- Suggest best practices endpoints format for the actual API implementations
Individual Requirements
Swagger doc should contain definitions for the following collections:
1). Search
Allow users to query the entire dataset on any word or number (text) contained in the database support incomplete word/number queries. As an example if someone is searching for all “complete” items ; the user can enter “comp” and have everything with those letters come up.
- Need to return the standards records with related data
- allow the use of search qualifiers such as “and”, “not”, and “or”
- allows user to search an email address
- filtering capabilities
-- ex1: find all contacts and committee participants for a Division or for a standard;
-- ex2: identify all Standards within a specific division)
2). Standard
- Need Support all CRUD endpoints
3). CnSIssue
- Need Support all CRUD endpoints
4). Standard Division
- Need Support all CRUD endpoints
5). Standard Division Contact
- Need Support all CRUD endpoints
6). Organization
- Need Support all CRUD endpoints
7). Division
- Need Support all CRUD endpoints
8). SubDivision
- Need Support all CRUD endpoints
9). Product Line
- Need Support all CRUD endpoints
10). Product Line Contact
- Need Support all CRUD endpoints
11). User
- Create 3 user roles:
- Administrator: Access to all application data, user management (add/edit all users), and access to modify data
- Data Manager: Access to add, edit, modify standards data and C&S Issue data
- Standard User: Access to view and search standards data, send notifications, and create and edit user’s own C&S issue data
- Need Support all CRUD endpoints
12). History
- Need Support all CRUD endpoints
General Filtering
The parameters should be returned in the response with the total count of matching records as well, It is preferred if the default values are configurable.
General Pagination
We need to add pagination when user scrolling the page, these endpoint should have the following parameters :
- offset (default 0)
- limit (default 15)
The parameters should be returned in the response with the total count of matching records as well, It is preferred if the default values are configurable.
Final Submission Guidelines
Scorecard & Review CriteriaWe’ll follow a subjective scorecard (1-10) for this challenge. The submissions will be evaluated on the basis of
- Completeness of Swagger file with respect to challenge requirements
- Adherence to best practices for designing REST API
- Accuracy of screen to API mapping
- Sample data on each endpoints.
What To Submit
- Swagger file
- Feel free to include any other document(s) that you think will help coders better understand how to implement the API