I'm asking about the way you divide the code and the patterns that you use.
For further actions, you may consider blocking this person and/or reporting abuse
I'm asking about the way you divide the code and the patterns that you use.
For further actions, you may consider blocking this person and/or reporting abuse
Rajesh Dhiman -
Yassine Sallami -
Dominique Megnidro -
Harsh boricha -
Top comments (9)
Why not follow an MVC pattern? i.e. one Controller per Entity and, in that Controller, you put all the endpoints for that entity.
Btw, this is the way Swagger generates the stubs from the APIs you design.
Many have recommended swagger.
Thanks for the reply
Great question. Answering this in a single comment is hard.
First, a few guiding thoughts:
Build something, refactor, build, refactor. Over time, you'll gain a sixth sense for where problem areas are emerging and where you might need to refactor or reach into your toolbox of patterns in order to help tidy something up. Don't beat yourself off for starting simple, if one file returns the stuff you need, it works, there's no shame in that.
Two big tips:
Write integration tests โ When you have a good set of integration tests, which test your contract from the outside-in you're going to have great confidence to refactor your code underneath. This is the biggest tip I can give you.
Use an inversion of control pattern โ I often write the same utility in all my REST API's, it's a utility that takes some input, validates it, passes the input to a handler, and it takes the response of the handler and passes it back to the client. The benefits of doing so are bigger than I could explain here. But this pattern creates a VERY nice separation, and creates a great central piece of code to add logging, error handling, etc. I do cover this pattern in this article: thedevcoach.co.uk/error-handling-j... ... let me know if you read it and if you have any questions.
Some other random thoughts on API building...
The main goal: If you can get your business logic to be as expressive as possible, so that it describes the custom rules of your application (when you strip away all of the technical details) you've WON the game.
Best of luck Sharad! Hit me up if you have any questions!
Thank you so much ๐, It's really helpful to me.
Yuss I'll ask more xD
If you are talking about actual endpoints, have a look at this talk: Cruddy by design. If you meant code architecture, then the talk will still offer plenty of inspiration in how Laravel achieves this.
Will look at it, Thanks ๐
I think the most important is separating the files into components that can change independently
Perhaps follow NestJS-like pattern?
Not sure how people do on Ruby on Rails, Java Spring, or Groovy on Grails, though.
Pretty sure that HATEOAS or hypermedia is implemented in bigger frameworks.
I will read up on everything and anything written by twitter.com/philsturgeon He has tons of resources on API design