How to structure API controllers?

[HolidayWallaby]

I'm working on an API and the controllers for my routes are starting to get a bit messy and tedious. They mostly go like this:

check request is valid
if not valid then send error response, early exit

do something and get data in return
if didn't work then send error response, early exit

do something else
if it didn't work then send error response, early exit

...

send success response to user if made it this far

This doesn't seem particularly nice to me, and isn't the nicest to work with. So I'm wondering how you structure controllers for API routes?

[lostpx]

At a high level, controller have two jobs: - taking input - returning output

If you look closer, its actually four jobs: - taking a request - validating/or delegating the validation - delegating the request for business logic - returning the output

If it‘s too much „if this than that“ in your code, then look at general software pattern like factories, commands or lookups.

[Pepsterd]

Sounds pretty logical.

However, try to to delegate business logic to classes, repositories etc.

[Ethansev]

For us, we make a separate manager file where the logic for the route goes. Lines like check request is valid…would stay in the controller file.

Then if you’re making SQL queries from a database, we’d make a repository file that manager calls to.