StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POREST Complex/Composite/Nested Resources
text
Body
copied!<p>I'm trying to wrap my head around the best way to address concepts in a REST based API. Flat resources that don't contain other resources are no problem. Where I'm running into trouble are the complex Resources.</p> <p>For instance I have a resource for ComicBook. ComicBook has all sorts of properties on it like author, issue number, date, etc. </p> <p>A comic book also has a list of 1..n covers. These covers are complex objects. They contain a lot of information about the cover, artist, date, and even a base 64 encoded image of the cover. </p> <p>For a GET on ComicBook I could just return the comic, and all of the covers including their base64'ed images. That's probably not a big deal for getting a single comic. But suppose I am building a client app that wants to list all of the comics in the system in a table. The table will contain a few properties from the ComicBook resource, but we're certainly not going to want to display all the covers in the table. Returning 1000 comic books, each with multiple covers would result in a ridiculously large amount of data coming across the wire, data that isn't necessary to the end user in that case. </p> <p>My instinct is to make Cover a resource and ComicBook contains covers. So now Cover is a URI. GET on comic book works now, instead of the huge Cover resource we send back a URI for each cover and clients can retrieve the Cover resources as they require them.</p> <p>Now I have a problem with creating new comics. Surely I'm going to want to create at least one cover when I create a Comic, in fact that's probably a business rule. So now I'm stuck, I either force the clients to enforce business rules by first submitting a Cover, getting the URI for that cover, then POSTing a ComicBook with that URI in the list, or my POST on ComicBook takes in a different looking Resource than it spits out. The incoming resources for POST and GET are deep copies, where the outgoing GETs contain references to dependent resources. </p> <p>The Cover resource is probably necessary in any case because I'm sure as a client I'd want to address Covers direction in some cases. So the problem exists in a general form regardless of the size of the dependent resource. In general how do you handle complex Resources without forcing the client to just "know" how those resources are composed?</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload