REST - expanding relationships

Question

I am creating an event management system. The circuit is described below. The API understands these relationships and returns links to related resources as a result of the request. For instance,

GET /Events/1 "links": { "Venue": "/Venues/1", "Tickets": "/Tickets?event_id=1", "Teams": "/Teams?event_id=1", "Registrations": "/Registrations?event_id=1" } 

Most of what I read about REST and HATEOAS suggests that this is the “right” way to do this, but it is very inefficient. For example, if I want to generate a report of users and teams participating in an event, this requires a lot of queries. This is similar to running multiple select queries instead of running a single database connection request. So my question is: should I expand relationships and embed related resources in a resource request? This also creates a b / c problem, the above query returns a lot of data. The answer may be to stick with relationship relationships and set up proper caching. Regardless, I would like your opinions.

 Schema events hasMany registrations hasMany tickets hasMany teams team belongsTo event ticket belongsTo event hasMany registrations user hasMany registrations registrations belongsTo event belongsTo ticket belongsTo user belongsTo team 

Answer 1

There is nothing wrong with returning the full representation of resources in the body of another request. It may be on the verbose side, though, as you mentioned.

Given that some callers of the service may only need to return a URI, but sometimes you want to reduce the number of round trips through the network, i.e. you want everything to be in one call, the term you are looking for is forecasts.

These are different representations of your resources, satisfying customer needs.

You can specify them in the URI parameter, for example, GET /Events/1?venueProjection=full,teamProjection=uri

And then return the projection as requested by the client.

 "links": { "Venue": { "uri": "/Venues/1", "attr1": "value1", "attrN": "valueN" }, "Tickets": "/Tickets?event_id=1", "Teams": "/Teams?event_id=1", "Registrations": "/Registrations?event_id=1" } 

Note. . Always return the URIs with your projections so that if they are not populated, the client has easy access to the full resource later.

I suggest you read something around Google’s “holiday forecasts” or check out the RESTful Cookbook.