novel heron
In a rest API, let's say that we have 2 resources Candidate and JobApplication.
A candidate can make multiple application and an application is only related to a candidate.
It's a OneToMany / ManyToOne relationship.
What is the best "REST routes" for a CRUD ? Should I make a JobApplication controller even if the applications can only be made by a candidate ? Or should I define my routes in the CandidateController ( eg. POST /candidates/job-applications .. ) ? Thanks !
earnest wave
application and candidate are separate subjects
so i would suggest to do what you where saying
dont mix things up, if you need to branch out things will get confusing otherwise
that's my take on it at least
novel heron
application and candidate are separate subjects
so i would suggest to do what yo...
So to make it clear, you would suggest to make 2 separates controller ? Thanks !
earnest wave
But that's how i see things, but best is to get more opinions then mine and make your final judgdment
I prefer it this way as it makes more sense and keeps things from getting mixed in my sense
novel heron
Ok thanks !
young cobalt
I'm going to go against the grain here and say that it depends on what your end goal is.
I built a recipe tracker which initially had an ingredient and a recipe module with controllers and module classes for each
I ended up combining them after ealizing that an ingredient on it's own didn't make a ton of sense.
To put it another way, I'd suggest thinking about how you want to interact with your API. Are you going to want CRUD for candidates and job applications? You might or you might not, but don't just build out a bunch of CRUD operations because "that's what's normally done.
I like to pretend I'm building a module other people might use like TypeORM then think "okay, if I was consuming this module, "would it make sense to me to access the Candidate service by importing the JobApplication module?"
I could argue both cases and ultimately it depends on what you're going to end up needing to do.
earnest wave
like i mentioned, it's just how i prefer it
for small scaled apps you can do that, but for me it gets to messy, to tie the loose ends
but if you wana keep things in 1 place it's fine
do what seems most logical for me
i reworked my end points just to get things on the right place
lets say we got a controller for users and accounts
then where does the end point belong that lists all accounts that has a property called users
in other words include all accounts+users