1

Let's say I have the following entities that can be accessed at the following URIs (using the standard pluralization):

/things/:id and /otherthings/:id

I want to expose for performance reasons, an api that will response with the following structure:

{
   "things": [],
   "otherthings": []
}

The call is so that my clients can retrieve all entities in a single call, instead of making two separate calls to /things and /otherthings.

My question
Would it make sense to wrap this in a call to /thingscontainer or something and consider it a new entity? I only want to expose a GET for the call to get the "container" with both collections, and all further interactions with the entities or entity collections themselves will hit their own appropriate "things" endpoints.

The "container" object approach I'm outlining seems like it might not be very RESTful. I'm fine with that but would like any ideas on ways to avoid deviating from it if possible.

2

Yes, that's just fine. What you are actually doing is creating a new resource: thingscontainer. The name is a bit vague though. Mostly because it's very abstract.

Bit more human language:

/allthings

{
  bigThings: [],
  smallThing: []
}

More concrete example could be search:

/searchresults/{searchId}

{
  websites: [],
  documents: []
}

I think that last example is really clear and there is absolutely nothing non-REST in it.

1
  • 1
    Thanks, I really like your search example. It convinces me this approach can be considered RESTful. My real objects have unrelated names, so in the abstract /allthings works, but for the real entities I'll now have to move onto the hardest problem in programming - naming things ;) – Ryan Weir Oct 5 '16 at 15:41

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.