Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Executive summary: Either is fine. I'd go with #1 with the caveat that you do it in at least two, possibly three requests. One to PUT the car, followed by another to POST the owner/driver. If you don't have the full resource data for the car beforehand, do a GET for that before the PUT, updating your PUT request body as necessary. If the GET returns 404, then just leave the unknown fields blank in your PUT, and define that your server will fill them in with default values (rather than, say, reject the PUT request).</p> <p>Long answer:</p> <p>REST does not dictate what the format of your message body should be.<br> The only constraints REST incurs upon you are:</p> <ol> <li>The uniform interface, in this case, HTTP's <code>POST</code> method. Using POST means you intend to append a new resource defined by the request body to the collection identified by the target URI. If doing so requires that the server must also create a resource elsewhere, then so be it.</li> <li>A documented, preferably common media type. Either use an existing media type (e.g. <a href="http://stateless.co/hal_specification.html" rel="nofollow" title="HAL Specification">application/hal+json</a>) or document the one you create.</li> <li>Use hypermedia (i.e. links) to advance the application state (browser window). In the request body, you can send whatever you like. It is the server's responsibility in its response to provide a hyperlink between car and person.</li> <li>The request must be self-contained. This means that you cannot, say, send one request to "set the current car to 66H8800" and then a second request to "create a driver for the currently set car". Doing this requires server state to be remembered between requests, which is forbidden in REST (as it breaks many things, like load balancing). It appears you are not doing this, but I can't tell from the code provided.</li> </ol> <p>It is your media type that dictates whether or not a "license" key should exist. Choose or create one as you see fit.</p>
    singulars
    1. This table or related slice is empty.
    1. PORest API: reasonable to create associated resources given a verbose representation?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USNicholas Shanks
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PORest API: reasonable to create associated resources given a verbose representation?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI'm still working through your answer to understand the principles. As for "either is fine", in that case doesn't it make sense to go with #2, so as to remove the need for any checking logic on the client's side?
      singulars
      1. PO
      1. USeoinoc
    2. COYes, if you want. But in that case I would not use "_links" as the name of a property that doesn't contain links ;-) Just be sure to document the format if you want it to be RESTful. #1 is so close to HAL that the effort required to dream up an almost identical custom format and then describe it is much less than that required to parse the link, and less versatile for the future. Please read [Roy's rant](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven), in particular the last bullet point, "A REST API should [use a] set of standardized media types". **SHOULD**, not MUST.
      singulars
      1. PO
      1. USNicholas Shanks
 

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