Databases
StackOverflow2013
Postsdbo
POREST resource representation with links, compatible with PUT and GET
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POREST resource representation with links, compatible with PUT and GET
    primarykey
    data
    text
    <p>I have been asked to design and implement a RESTful API, and have been researching best practices, but so far have only a woolly concept about resource representations. Most of the available examples I found seem to focus heavily on API clients that walk connected structures using a series of GETs.</p> <p>I have looked at:</p> <p><a href="http://www.restapitutorial.com/media/RESTful_Best_Practices-v1_1.pdf" rel="nofollow">http://www.restapitutorial.com/media/RESTful_Best_Practices-v1_1.pdf</a></p> <p><a href="http://www.youtube.com/watch?v=HW9wWZHWhnI" rel="nofollow">http://www.youtube.com/watch?v=HW9wWZHWhnI</a></p> <p>amongst other online resources (I am limited to 2 links sorry cannot list them all). They are all great, but don't really address my design question. </p> <p>Most of the best practice documents suggest two things that to me look slightly in conflict:</p> <p>1) REST service should represent data relationships as links between resources</p> <p>2) A "PUT" request from a client should be a full representation, identical in form to the representation seen on the server.</p> <p>The trouble from my point of view is that the links, and perhaps quite a few other properties in a typical resource, are read-only, so cannot be updated. The server apparanetly shoudl expect them as-is, and return an error if it thinks the client is trying to update them. In fact, when I look at a typical resource represented in JSON, the majority of it is data that logically cannot/should not be replaced. E.g.</p> <pre><code>{ "link": { "rel":"self", "href":"http://example/project/12345" }, "team": { "link": { "rel":"self", "href":"http://example/project/12345/team" }, "title": "The project team" }, "title": "The Big Project" } </code></pre> <p>Here at best only the two title texts would be writable to a client on this resource (team membership might be alterable via the team link).</p> <p>So should I be requiring that a PUT includes all the "link" elements exactly as-is, which are purely logical and read-only (note in the example, the team cannot be re-linked, as the resource defines it as the team for the project - in this case that could be changed, but for many resource types with stricter containership, this doesn't apply)? </p> <p>Are there standard patterns or anti-patterns for representing resources in REST with many links? I'm not being asked for a specific REST variant, such as HATEOAS though my inclination is to aim at theoretical "correctness" where possible. In other words, if "official" REST would be to expect clients to PUT the whole resource, links and all, then that is probably what I will do.</p> <p>Some examples of real world complex non-leaf REST resources that support GET and PUT, and thus have to work with this issue, would be really appreciated. When I search I get lots of opinion, and many examples showing how nicely GET works . . . but so far I have not seen a well-documented example showing a PUT to anything but a trivial leaf resource (i.e. one that does not contain any links, except perhaps a self reference).</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USNeil Slater
    1. USNeil Slater
    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. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POREST resource representation with links, compatible with PUT and GET
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POREST resource representation with links, compatible with PUT and GET
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POREST resource representation with links, compatible with PUT and GET
      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