How do you handle relations / nested objects?

[fr3fou]

Hi, great articles, I found them very helpful!

I have a question regarding how do you handle relations in a REST API. I find myself thinking about this a lot while making REST APIs and it quite often it gets me stuck.

• When do you return nested objects / relations? Do you always return them? Do you expose query params that help you do that (kinda like a self-made-GraphQL)
• Would you return nested objects / relations when accessing an endpoint which returns an array? (i.e in a shop app /categories/ also returning all the products in each category). In my case if I don't - I will end up with the N+1 problem, but if I do, sometimes the code gets quite complex.
• Where would you handle "authorization" for different fields (i.e imagine a normal user tries to access /categories and categories have an associated owner. We don't want to return private information about the owner in each category and only return information such as CategoryName, CategoryImage etc. This is opposed to an Admin accessing /categories, we want to return all the fields to that user). I've tried handling this in my http layer and my service layer and it ends up being clunky in both.

I generally have issues planning out my API endpoints and end up overthinking / accounting for stuff I won't need / not focusing on the important endpoints (because I don't know which are going to be "important").

[benbjohnson]

When do you return nested objects / relations? Do you always return them? Do you expose query params that help you do that (kinda like a self-made-GraphQL)

I typically start with returning nested objects & relations. Usually just parent relationships (e.g. attaching a Customer onto a returned Order object). Most APIs only have one or two endpoints that are called a lot so I'll optimize those with a query param if I really need to restrict the returned data.

Would you return nested objects / relations when accessing an endpoint which returns an array? (i.e in a shop app /categories/ also returning all the products in each category). In my case if I don't - I will end up with the N+1 problem, but if I do, sometimes the code gets quite complex.

No, generally I don't return child relationships because of N+1 queries. The size of your data can really explode too. I find that having the caller request extra data with a query param or just an additional API call works better.

Where would you handle "authorization" for different fields (i.e imagine a normal user tries to access /categories and categories have an associated owner. We don't want to return private information about the owner in each category and only return information such as CategoryName, CategoryImage etc. This is opposed to an Admin accessing /categories, we want to return all the fields to that user). I've tried handling this in my http layer and my service layer and it ends up being clunky in both.

It depends on the exact details of the restrictions and authorization. For simple cases like clearing individual fields on an object, I'll add a helper function in my domain package called something like Order.ApplyAuth(ctx) that checks the user from the context and clears out fields based on their auth.

For more complex cases, I usually find myself adding it into the data access layer so I can filter results by what the current user can see or do.