The task: Create an application that exposes an endpoint,
Op | URL | Payload | Params |
---|---|---|---|
GET | /num_to_english | Body,JSON | N/A |
GET | /num_to_english_param?number=123 | N/A | number parameter |
POST | /num_to_english | BODY,JSON | N/A |
Which has the following Request Body Format, where a number is passed in the number field.
NOTE Sending A request body payload on a GET request is usually considered illegal and bad practice, but it works in some tools/frameworks.
{
“number”: “12345678”
}
This endpoint will convert any number given to it into the english words that describe that number. For example the above request should respond in the following format.
{
“status”: “ok”,
“num_in_english”: “twelve million three hundred forty five thousand six hundred seventy eight”
}
status is reserved for messaging back if the process succeeded or failed. Make sure to use that when handling errors.
Here's a better approach. Send the number as a parameter.
Use the same Request Payload as defined for the GET with the message body A POST of this data is better supported and more rational. However, it might cause some confusion because POST is usually for creating a new entity and that is not being done in this case.
Treat this as a production endpoint you would publish. How would you organize it to be production ready? What are the things you would do to allow other engineers to use your endpoint?
These would be necessary for production readiness
- HealthCheck (handled by Actuator)
- Docker Image
- Not Implemented but important
- Configurable options, to be passed in through environment variables
- Authentication methodologies
- API key & secret, OAUTH, etc?
- Authorization methodologies
- Define needed granularity
- Kubernetes,DC/OS,Helm-charts, etc
- API Versioning
- Swagger / OpenAPI specification
- Numbers may be from 0 to Integer.MAX_VALUE (2147483647)
- It could have been bigger... Arbitrary choice
- Commas will be removed from the input number
- Numbers should be expressed in base ten