Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The answer is that your application (in a REST scenario) simply <em>doesn't</em> keep track of what happens. All state is managed by the client, and state transitions are effected through URI navigation. The "State Transfer" part of REST refers to client navigation to new URIs which are new states.</p> <p>A URI accessed with GET is effectively a read-only operation as per both the HTTP spec and the REST methodology. That means if the client "backs up" to some previous URI, "the worst" that happens is another GET is made and more data is loaded.</p> <p>Let's say the client does this (using highly simplified pseudo-HTTP)...</p> <p>GET //site.com/product/123</p> <p>This retrieves information (or maybe a page) about product ID 123, which presumably includes a reference to a URI which can be used to POST that item into the user's shopping cart. So the user decides to buy the item. Again, it's oversimplified but:</p> <p>POST //site.com/shoppingcart/ {productid = 123}</p> <p>The return from this might be a representation of the shopping cart, or a reference to the added item (which could be used on the shoppingcart URI with DELETE to remove the item again), or a variety of other things (such as deeper XML describing the cart contents with other URIs pointing to the cart items and back to the original products). It's all up to you.</p> <p>But the "state" is defined by whatever the client is doing. It isn't tracked on the server at all, although you will certainly keep a copy of his shopping cart contents in your database for some period of time. (I once returned to a website two years later and my shopping cart items were still there...) But it's up to him to keep track of the ID. To your server app it's just another record, presumably with some kind of expiration.</p> <p>In this way you don't need cookies, and javascript is entirely dependent on the client implementation. It's difficult to build a decent REST client without script -- you could probably build something with XSLT and only return XML from the server, but that's probably more pain than anyone needs.</p> <p>The starting point is to really understand REST, then design the system, then build it. It definitely doesn't lend itself to building it on the fly like most other systems do (right or wrong).</p> <p>This is an excellent article that gives you a fairly "pure" look at REST without getting too abstract and without bogging you down with code:</p> <p><a href="http://www.infoq.com/articles/subbu-allamaraju-rest" rel="nofollow noreferrer">http://www.infoq.com/articles/subbu-allamaraju-rest</a></p>
    singulars
    1. This table or related slice is empty.
    1. POKeeping track after the back button
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USMcGuireV10
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POKeeping track after the back button
      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. 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. COYou bring up a scenario I'm confused about. If you returned to that cart two years later, how did the web site know it was you and not someone else without using cookies? You didn't say you had to login with a name/password so did you? Or are you saying the client is responsible for their own cart and if an outsider gets hold of the URI, it's not our fault? I'm just in a fog at that point because I can't find anything that talks of this (haven't read your article reference yet). If a client has a URI to a form containing an order, how does the site prevent anyone from modifying it?
      singulars
      1. PO
      1. USRob
    2. COThat was just an aside, but yes, I did login -- that wasn't a REST system, and it did use cookies, although mine had expired. I was simply referring to an amusing example of long-term expiry of shopping cart data. But security and authentication are not a concern of the pure REST concept. Essentially the client supplies credentials with every call, but how is up to the API. It appears that the most obvious and simple solution is SSL plus HTTP basic auth (which is good enough for online banking, after all).
      singulars
      1. PO
      1. USMcGuireV10
    3. CONote that REST could still be used to create an anonymous shopping cart (no login), but it would only be accessible as long as the client knew the URI to the cart ID. By definition the client could save this URI and access it later (e.g. bookmark it), so it isn't correct to think of this as a sort of poor-man's session, but it's similar to that. But if the user or client didn't store the URI, then it would essentially become orphaned data if it wasn't associated with a login (and hopefully, would eventually be aged off the table).
      singulars
      1. PO
      1. USMcGuireV10
 

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