Best practice for return data from API
I'm building a small employee scheduling app to learn .NET. I have an API endpoint that returns all shifts for a given date range, grouped by an employee ID, shifts are nested to each employee id and ordered by date.. I'm not sure if my approach is good. When I'm going to consume this in my front end, I want to show the employees name, not their ID. Would it be better to include this in the response from the shifts endpoint, or for the frontend to pull the name from Employees endpoint when parsing the shifts?
6 Replies
So if I'm understanding correctly, the problem is you're returning a collection of shifts that reference an employee ID and you don't want to call a "GetEmployeeProfile" endpoint for every record in the collection to display each of their names?
Basically yeah, it seems a bit over the top to call for the leader name for each set of shifts
The solution for this would likely live in the SQL query(i'm assuming you're using SQL), you can group ID,NAME in the response
your instinct is right on this, it doesn't make sense to call one endpoint for the info you need, then X endpoints to complete that info...
I'm using EF core with SQLite atm
yeah that was my thinking. Right now I pull a list of shift in a given date range. Then groupby on that list to nest it to each employeeID. It made sense to do it that way as the client would have an easier time to parse. When I was grouping, I tried to include the employee name but it was giving unexpected entries in the json response
unfortunately i'm a little out of practice with EF core so can't advise you of that
the other option you have with this is to make a "bulk info" endpoint, where you pass in multiple IDs and it presents multiple profiles in return
that way seems maybe cleaner from an architecture perspective, you're not returning random info in different types of queries, instead there's a single place to get info for every type of operation you're doing
in this way instead of calling 1 endpoint + x for the size of collection, it's just 2 endpoints
yeah that was my other way, have my frontend call and get a list of employees with ID, and use that when parsing the shifts
as the list of employees isn't that long for what I'm doing (15 at most)
so it's 2 endpoints instead of 1 + x
Good to know I was thinking about it the right way, thanks!
I went back and looked, and for whatever reason I forgot to include an employee nav property as part of the shift entity, added it, migrated now I can load everything from the single endpoint