RESTful API design - how to best represent child entities? - Ask Schneids
I recently got an email from a friend of a friend asking me to advise them on a REST API they were designing. I’ll happily give you advice, I reply. Would you mind if I posted it for others to benefit? He replied, yes, go ahead!
I think I’m going to make this a regular thing and call it Ask Schneids. Feel free to email me your questions (or contact me any way you like – just make sure to include Ask Schneids somewhere in the body or subject so I know it’s okay to post) and I’ll respond to them and post the answers to this blog. I’ll make sure to remove any identifying information from the question before I post it.
Anyways, without further ado, here’s my very first Ask Schneids question regarding RESTful API design. Comments and follow up questions are always welcome – if you disagree, leave a comment below so we can all learn together! 🙂
How do you best return related entities?
I’m starting on a major refactoring, you could call it a rewrite, and one of my goals is to create an “API first” application using ASP.NET Web API and Entity Framework.
Our data is highly relational and I’m curious how to best return those complex objects/relations in JSON. For example “inventory” is made from entities: “items”, “locations” and “unit of measure”, along with other properties like quantity, last change date, user, and other attributes to identify that specific instance of inventory. “items” and ‘locations” both have additional properties and related entities, the usual: name, description, etc, but can also include a list of images, a list of item aliases, among other things.
Basically my question is: how much of the related entity should be included when “inventory” is requested? Just an Id, include the “core” info from the entity, or include the complete entity? Of course it depends. 🙂
Of course it depends! It always depends. 🙂 Typically it’s going to depend on your consumer. Sounds like the API is going to consumed by both internal and external users. Consider returning only a subset (or the “core”) of the most important data in a call with a related entity and expose an API that allows them to get more data if they request it. For example, your inventory object might return the Item name and description, but allow you to get the additional data from the Item API if they need it.
I always recommend passing data from domain objects (e.g. objects specifically tied to a database, such as Entity Framework entities) to dumb DTOs (like view models, but for API’s) that are simple property bags. You can use AutoMapper to do this quite easily. Check out the Model Factory pattern here for an example (but don’t create the ModelFactory class and write all that repetitive, boring code – just use AutoMapper!)
Should you get individual records with the database ID or some other kind of unique identifier?
This is a multi-tenant app, and with that I’m struggling with whether or not to expose and use the system Id to the end user (PK of the entity in the database). A user creates an item: Widget101, of course it gets and Id from the database, say 2345. Do you get the item like:
api/v1/items/2345
or
api/v1/items/Widget101
Best practice is to allow them to get the object via the database ID – it’s meaningful to your system and simpler for API construction. If you need to expose a way to get the Item using another identifier (e.g. Widget101), consider using OData practices ($filter parameter would be a good place to start.) You can find more information on implementing OData in ASP.NET Web API here.
For more REST implementation best practices, I really like Microsoft’s REST API guidelines found here. They’re very comprehensive and are a good starting point for any REST API developer (ASP.NET or otherwise.)