1

I am trying to design business entities in .NET like below which will be exposed via Web API/oData.

Business Entity 1 : "Vehicle" with the properties as below:

  • VehicleId string
  • ModelId string

Business Entity 2 : "Model" with the properties as below:

  • ModelId string
  • ModelDescription string

Now if someone uses my Web API to fetch Vehicle information only and wants to display Model description also then they need to make 2 HTTP calls which will result in degradation of performance specifically in slow networks. In this scenario I would like to know what is the best way to load & model nested business entities which will provide optimum performance via Web API?

Shall I model my Vehicle class as below and is it really a good practise for a REST/Web API design? For the below approach the entity seems to become too heavy also due to contained entities also. Please advise.

Business Entity 1 : "Vehicle" with the properties as below:

  • VehicleId string
  • ModelId Model
abatishchev
  • 98,240
  • 88
  • 296
  • 433
DIP
  • 11
  • 1

2 Answers2

1

It all depends on what's consuming your API and how it recognizes and persists one-to-many relationships. Write your API so that your first consumer can call it in a performant fashion, then worry later about tweaking it.

For example, in an Ember.js app using Ember Data, you have a choice of returning child IDs, or you can embed the entire child as a property on the parent as well and it will be deserialized and tracked on the client as an individual model. Whether you want to do it one way or the other depends entirely on your application flow. I recognize that Ember Data is not OData, but the concept is the same.

I don't think there's a good "this is the way to do it" answer without considering both the client and server.

moarboilerplate
  • 1,633
  • 9
  • 23
  • Thanks for your answer. I am trying to find the best approach for my Web API development since I have no control/knowledge till date on type of JavaScript frameworks my end clients will be using to consume the Web API. I want to keep it flexible and also still design my Web API to serve them with optimum performance in both the scenario's I mentioned above. – DIP Jul 30 '15 at 17:28
1

I would probably create Vehicle and Model as

public class Vehicle
{
    public string Id { get; set; }
    public string ModelId { get; set; }

    public Model Model { get; set; }
}

public class Model 
{
    public string Id { get; set; }
    public string Description { get; set; }
}

When your API client requests a vehicle, I would populate Model property if needed and would leave it as null if this information is not necessary.

This way you have a flexibility of not loading model information if you just need vehicle data while having while having to do only 1 API call in case you need both vehicle and model. This will also work well with a database with foreign keys and any ORM framework,

Nikolai Samteladze
  • 7,699
  • 6
  • 44
  • 70
  • Thanks for your answer. The only concern I have is by the above approach the Vehicle entity duplicates the same property value i.e. ModelId and Model twice which makes the Vehicle entity looks a bit diluted. Still it is true that till date I could not find any other better solution. – DIP Jul 30 '15 at 17:22
  • Such replication actually allows you to be more flexible with your data assumptions (e.g. you know you model id, but don't have any details about the model) and with your class hierarchy usage scenarios (e.g. you can make `Model` property lazy and load this data only when needed). Also, you will see that a lot of tools (e.g. Entity Framework) follow the same convention. – Nikolai Samteladze Jul 30 '15 at 17:30