3

I have a question about the way I am architecting an API.

Structure

My API structure so far is like so (there is about 10 classes total, but many are similar, so I've reduced to these classes, and removed fields that are not relevant to the question):

Profile

  • id (unique identifier for this Profile)
  • Allergies
  • X-Rays

Allergies

  • id (unique ID for this allergy)
  • Profile (this points back to the Profile that owns these allergies)
  • name (what they are allergic to)

X-Rays

  • id (unique ID for this X-Ray)
  • Profile (points back to the Profile that owns these X-Rays)
  • thumbnail (a compressed version of the X-Ray image)
  • fullImage (the full, uncompressed X-Ray image)

Use Cases

  • Profiles are sent down the wire in full, except that in the X-Rays class, the thumbnail is sent instead of the full image. When the user wishes to see the full X-Ray image, then they make another call to download the full image (this is done to save bandwidth, it's possible that a user has 100 X-Rays at 10MB each!).

  • A user can make modifications to Allergies or X-Rays, and these changes would have to be sent back to the server. It'd be wasteful to send the entire Profile object back, so I'd like to send just the individual X-Ray or Allergies object back to the server.

Concerns

What should my API return (the response format will be JSON) when a user downloads a full profile?

{
  "Profile": {
    "id": "1234",
    "Allergies": { 
      "id": "5678",
      "Profile": {
        "What goes here? This is a circular reference!
         I need to include a reference back to the profile
         so I can edit this Allergy client side and push the changes.
         Maybe it should be the User ID of the profile,
         but I'm not so sure that is a good idea"
      },
      "name": "peanuts"
    },
    "X-Rays": {
      "id": "3456",
      "Profile"{
          ...
      },
      "thumbnail": "Base 64 encode of the thumbnail image"
    }
  }
}
1
  • 2
    I have too little experience with this to write a good answer, but I'm surprised that your design seems to forbid n:m relations between profiles and allergies / that each allergy needs to belong to one profile. There is no reason for loops to be present in this object graph, since “allergy X belongs to profile 1234” is already implied by “profile 1234 has allergy X” – you only need to encode this information once. Also, it's easy to break nesting by switching to IDs instead, and appending an allergy dictionary with lookup by ID to the response.
    – amon
    Nov 27, 2014 at 16:24

1 Answer 1

4

It looks like you are confusing your underlying model objects with your API resources, they are not necessarily mutually exclusive. If you are simply serializing your classes as JSON, you going to duplicate content (and get the profile appearing several times) which is not needed and a smell.

You could:

Create specific resource models that represent your resources better (kind of like View Models in a MVC Framework). So you could create model objects such as PatientResource, XRayResource and a AllergyResource (you don't have to suffix the name Resource here, they could just sit somewhere separately to your other models). that better represent what your clients need to consume instead of every property of the domain model.

c# here:

public class PatientResource
{
    public int Id { get; set; }
    public IEnumerable<AllergyResource> Allergies { get; set; }
    public IEnumerable<XrayResource> XRays { get; set; }
}

public class AllergyResource
{ 
    public int Id { get; set; }
    public string Name { get; set; }
    public int ProfileId { get; set; }
}

public class XrayResource
{ 
    public int Id { get; set; }
    public string Name { get; set; }
    public int ProfileId { get; set; }
}

All very basic, the allergy and xray resource do not hold profile objects, they hold a reference id for a profile, even that would look slightly out of place, so you may need to restrict some properties depending on where your data is consumed, for example, do you really need to show an profileId if you are representing an AllergyResource in the AllergyResource collection of a PatientResource, probably not, so for that serialization you would omit that property. However, if you were in a standalone AllergyResource you would probably like to show the reference.


I like to use links in my API's

I don't really know what flavour of API you are creating (RESTFul, RPC, HATEOS etc) so this may not apply. I mainly deal with REST style (some may not be REST in the truest sense of the word) but when i am building an API i like to be a succinct as possible with my response objects but give the clients the ability to discover linked resources via links. This can be as complicated or simple as you like, you can use JSON or a more specific media type like HAL+JSON but the point is, you send your resources down the wire, and you enable the discover-ability of related resources via standard HTTP links.

BasecampX as an example: where they have a person, but the todo list is available at another resource endpoint which is specified in response. The objects are simplified but it does make calling the API more verbose in that multiple requests are required. It really depends on how your clients will consume the data and work with it.

1
  • "It looks like you are confusing your underlying model objects with your API resources" This was exactly what I was doing. Thank you very much for your insight. I think I better understand how I should build out this API now! Nov 27, 2014 at 19:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.