Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Treating covers as resources is definitely in the spirit of REST, particularly HATEOAS. So yes, a <code>GET</code> request to <code>http://example.com/comic-books/1</code> would give you a representation of book 1, with properties including a set of URIs for covers. So far so good.</p> <p>Your question is how to deal with comic book creation. If your business rule was that a book would have <strong>0 or more</strong> covers, then you have no problem:</p> <pre><code>POST http://example.com/comic-books </code></pre> <p>with coverless comic book data will create a new comic book and return the server generated id (lets say it comes back as 8), and now you can add covers to it like so:</p> <pre><code>POST http://example.com/comic-books/8/covers </code></pre> <p>with the cover in the entity body.</p> <p>Now you have a good question which is what happens if your business rule says there always must be at least one cover. Here are some choices, the first of which you identified in your question:</p> <ol> <li><p>Force the creation of a cover first, now essentially making cover a non-dependent resource, or you place the initial cover in the entity body of the POST that creates the comic book. This as you say means that the representation you POST to create will differ from the representation you GET.</p></li> <li><p>Define the notion of a primary, or initial, or preferred, or otherwise-designated cover. This is likely a modeling hack, and if you did that it would be like tweaking your object model (your conceptual or business model) in order to fit a technology. Not a great idea.</p></li> </ol> <p>You should weigh these two choices against simply allowing coverless comics.</p> <p>Which of the three choices should you take? Not knowing too much about your situation, but answer the general 1..N dependent resource question, I would say:</p> <ul> <li><p>If you can go with 0..N for your RESTful service layer, great. Perhaps a layer between your RESTful SOA can handle the further business constraint if at least one is required. (Not sure how that would look but it might be worth exploring.... end users don't usually see the SOA anyway.)</p></li> <li><p>If you simply must model a 1..N constraint, then ask yourself whether covers might just be sharable resources, in other words, they might exist on things other than comic books. Now they are not dependent resources and you can create them first and supply URIs in your POST that creates comic books.</p></li> <li><p>If you need 1..N and covers remain dependent, simply relax your instinct to keep the representations in POST and GET the same, or make them the same.</p></li> </ul> <p>The last item is explained like so:</p> <pre><code>&lt;comic-book&gt; &lt;name&gt;...&lt;/name&gt; &lt;edition&gt;...&lt;/edition&gt; &lt;cover-image&gt;...BASE64...&lt;/cover-image&gt; &lt;cover-image&gt;...BASE64...&lt;/cover-image&gt; &lt;cover&gt;...URI...&lt;/cover&gt; &lt;cover&gt;...URI...&lt;/cover&gt; &lt;/comic-book&gt; </code></pre> <p>When you POST you allow existing uris if you have them (borrowed from other books) but also put in one or more initial images. If you are creating a book and your entity has no initial cover-image, return a 409 or similar response. On GET you can return URIs..</p> <p>So basically you're allowing the POST and GET representations to "be the same" but you just choose not to "use" cover-image on GET nor cover on POST. Hope that makes sense.</p>
    singulars
    1. This table or related slice is empty.
    1. POREST Complex/Composite/Nested Resources
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USfamousgarkin
    1. USRay Toal
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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