All the API handling is currently implemented in a Controller class.
Consider splitting in two:
Controller: responsible of extracting the params, search/query params and body from the request, validating the extracted data, calling the service and returning the response appropriately (with the right http code).
Service: responsible of the business logic which can be extensive. The service functions have their own signature and should not have to deal with the request to get the data they need (the controller should do that). Because they are not related to the API request, Service functions can be called elsewhere, internally.
Main reasons for this ticket is because of the discrepancies in the Controller function to handle the request and the response.
There are many cases where the endpoints are not validating the params, explicitely accept them as undefined even if required, continue with the logic which eventually fails and catch the error to return a 500 even though a 400 Bad Request could have been returned earlier (or a 401 Unauthorized if the key - or whatever the auth - is missing).
Look at The Verida Missions API for the structure:
All the API handling is currently implemented in a
Controllerclass.Consider splitting in two:
Main reasons for this ticket is because of the discrepancies in the Controller function to handle the request and the response.
There are many cases where the endpoints are not validating the params, explicitely accept them as
undefinedeven if required, continue with the logic which eventually fails and catch the error to return a500even though a400Bad Request could have been returned earlier (or a401Unauthorized if thekey- or whatever the auth - is missing).Look at The Verida Missions API for the structure: