akrivohlavy / the-problematic-api

The Problematic API

Based on this template

This application allows you to put all your Problems away!

Quick-start

• npm install
• npm start
• Visit http://localhost:3000/

API

• Run npm run docs:start and visit http://localhost:8088/ to browse API docs

Development

• npm run start-lr

Collaborating

GitHub Issues and Github Project is used for simple kanban-style progress tracking. Check it out here.

License

This project is published under MIT license.

the-problematic-api's Issues

Implement endpoint for answering a Problem

Description

From the requirements:

User can answer a Problem. Only correct answers are accepted.
...

You should

...
Ignore existing solutions for the expression solver or built in JS functions (like eval). We will be impressed by your algorithm. If you can't make it, don't worry, an existing solver is better than none. The solver is also a single non-trivial business logic in the task.

Answer

• riddle: constant string "It is 42" (via static config)
• mathExpression: number (via arithemtic expression solver)

DoD

• user can answer Problems and know if their answer was correct or not
• 3rd party expression solver for Expression is sufficient for this ticket

Design API

Firstly we need to know what we are making. Therefore designing our API (in a machine-readable manner too) is the first step.

Definition of Done

• schema definitions
• defined routes
• openAPI - export file

Implement custom arithmetic expression solver

• Ignore existing solutions for the expression solver or built in JS functions (like eval). We will be impressed by your algorithm. If you can't make it, don't worry, an existing solver is better than none. The solver is also a single non-trivial business logic in the task.
  • (Bonus) Enhance your solver with binary operators */, unary operators -+ and operator precedence.

Implement required CRUD operations on Problems

Description

From the requirements:

• User can create a new Problem. A Problem can be either riddle or math expression - more on that below.
• User can update, delete, read and list Problems.

...

• Modify update, delete operations so that only users who created those Problems can perform this action.

Broken down to operations:

users desired action	parameters	response	notes
list	*filter by Problem type, answered/unanswered status	Problem[]
read
create	Problem	Created Problem URI	*validation
update	Problem		owner-protection, *validation
delete			owner-protection

* part of optional requirements

DoD

• each defined operation can be mapped to an endpoint
• update swagger and README
• integration tests cover CRUD lifecycle of a Problem, owner-protection and Basic Auth

Implement input validation

(Optional) Modify update/create Problem operations to validate the input data. Reject requests for empty problems and respond accordingly.

Implement filtering for Problem listing

(Optional) Modify Problems List to support filtering by Problem type and by answered / unasnwered for current user

Implement Basic auth

Authenticate users using Basic access authentication. No need to verify against any database - assume password is always correct. Use username from BA credentials to identify the User.

DoD

• all routes use BA middleware
• credentials verification is done in a stubby module, that is ready for a real verification against DB (async interface)