REST API wrapper - class design for 'lite' object responses

Posted by sasfrog on Programmers See other posts from Programmers or by sasfrog
Published on 2012-11-10T04:14:20Z Indexed on 2012/11/10 5:15 UTC
Read the original article Hit count: 171

I am writing a class library to serve as a managed .NET wrapper over a REST API. I'm very new to OOP, and this task is an ideal opportunity for me to learn some OOP concepts in a real-life situation that makes sense to me.

Some of the key resources/objects that the API returns are returned with different levels of detail depending on whether the request is for a single instance, a list, or part of a "search all resources" response. This is obviously a good design for the REST API itself, so that full objects aren't returned (thus increasing the size of the response and therefore the time taken to respond) unless they're needed.

So, to be clear:

  • .../car/1234.json returns the full Car object for 1234, all its properties like colour, make, model, year, engine_size, etc. Let's call this full.
  • .../cars.json returns a list of Car objects, but only with a subset of the properties returned by .../car/1234.json. Let's call this lite.
  • ...search.json returns, among other things, a list of car objects, but with minimal properties (only ID, make and model). Let's call this lite-lite.

I want to know what the pros and cons of each of the following possible designs are, and whether there is a better design that I haven't covered:

  1. Create a Car class that models the lite-lite properties, and then have each of the more detailed responses inherit and extend this class.
  2. Create separate CarFull, CarLite and CarLiteLite classes corresponding to each of the responses.
  3. Create a single Car class that contains (nullable?) properties for the full response, and create constructors for each of the responses which populate it to the extent possible (and maybe include a property that returns the response type from which the instance was created).

I expect among other things there will be use cases for consumers of the wrapper where they will want to iterate through lists of Cars, regardless of which response type they were created from, such that the three response types can contribute to the same list.

Happy to be pointed to good resources on this sort of thing, and/or even told the name of the concept I'm describing so I can better target my research.

© Programmers or respective owner

Related posts about object-oriented-design

Related posts about rest