What is a good REST convention for the structure of a response that is just a container of two (or more) unrelated entities

Question

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.

Answer 1

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.