Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would suggest the querystring solution (your first). Your arguments against the other alternatives are good arguments (and ones that I've run into in practise when trying to solve the same problem). In particular, the "loosen the constraints/respond to <code>foo/a</code>" solution <em>can</em> work in limited cases, but introduces a lot of complexity into an API from both implementation and consumption and hasn't, in my experience, been worth the effort.</p> <p>I'll weakly counter your "seems to mean" argument with a common example: consider the resource that is a large list of objects (<code>GET /Customers</code>). It's perfectly reasonable to page these objects, and it's commonplace to use the querystring to do that: <code>GET /Customers?offset=100&amp;take=50</code> as an example. In this case, the querystring isn't filtering on any property of the listed object, it's providing parameters for a sub-view of the object.</p> <p>More concretely, I'd say that you can maintain consistency and HATEOAS through these criteria for use of the querystring:</p> <ul> <li>the object returned should be the same entity as that returned from the Url without the querystring.</li> <li>the Uri without the querystring should return the complete object - a superset of any view available <em>with</em> a querystring at the same Uri. So, if you cache the result of the undecorated Uri, you know you have the full entity.</li> <li>the result returned for a given querystring should be deterministic, so that Uris with querystrings are easily cacheable</li> </ul> <p>However, what to <em>return</em> for these Uris can sometimes pose more complex questions:</p> <ul> <li>returning a different entity type for Uris differing only by querystring could be undesirable (<code>/foo</code> is an entity but <code>foo/a</code> is a string); the alternative is to return a partially-populated entity</li> <li>if you <em>do</em> use different entity types for sub-queries then, if your <code>/foo</code> doesn't have an <code>a</code>, a <code>404</code> status is misleading (<code>/foo</code> <em>does</em> exist!), but an empty response may be equally confusing</li> <li>returning a partially-populated entity may be undesirable, but returning part of an entity may not be possible, or may be more confusing</li> <li>returning a partially populated entity may not be possible if you have a strong schema (if <code>a</code> is mandatory but the client requests only <code>b</code>, you are forced to return either a junk value for <code>a</code>, or an invalid object)</li> </ul> <p>In the past, I have tried to resolve this by defining specific named "views" of required entities, and allowing a querystring like <code>?view=summary</code> or <code>?view=totalsOnly</code> - limiting the number of permutations. This also allows for definition of a subset of the entity that "makes sense" to the consumer of the service, and can be documented.</p> <p>Ultimately, I think that this comes down to an issue of consistency more than anything: you can meet HATEOAS guidance using the querystring relatively easily, but the choices you make need to be consistent across your API and, I'd say, well documented.</p>
    singulars
    1. This table or related slice is empty.
    1. PODifferent RESTful representations of the same resource
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USDan Puzey
    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. COI like the limited combinations idea. I decided to use it, but in the path rather than the query.
      singulars
      1. PO
      1. USJordan
    2. COThe caching points are important, especially about caching the result of the undecorated URI - the sole reason I'm supporting representations of a subset of a resource is to reduce the network and server load, and the best way to do that (assuming several requests to the same resource) is to cache everything the client might need to know about the resource and just get pieces of it from there.
      singulars
      1. PO
      1. USJordan
 

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