Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Different responses to different clients, for <em>same</em> URL is okay.</p> <p>StackExchange does it:</p> <pre><code>GET /me/comments/{toid} </code></pre> <p>which is documented <a href="https://api.stackexchange.com/docs/me-comments-to">here</a>.</p> <p>Twitter does it too:</p> <pre><code>GET /statuses/home_timeline </code></pre> <p>which is documented <a href="https://dev.twitter.com/docs/api/1/get/statuses/home_timeline" rel="nofollow noreferrer">here</a>.</p> <p>Both of those URLs infer the logged in user based on authentication. Yes, it defeats caching if users share a cache, but IMO, this is okay. Whether or not this breaks the 'resource identification' constraint of REST is probably debatable. The answer to <a href="https://stackoverflow.com/questions/3408191/is-the-twitter-api-really-restful">this</a> question, and a subsequent comment there shows to me why it is debatable.</p> <p>In fact, among the options, you <em>do</em> mention URLs which are not 'context sensitive':</p> <pre><code>GET /api/mails?senderUserId=109&amp;receiverUserId=110 </code></pre> <p>This one will always return messages from 109 to 110. But while one client would want to see this result when viewing 'sent' messages, the other would want to see this result when viewing 'received' messages. Kind of weird eh? Plus, on the server you'll have to check that the authenticated user is 109|110, else throw a <code>401 UNAUTHORIZED</code>.</p> <p>I would go with something like:</p> <pre><code>GET /mail/sent </code></pre> <p>returns all sent mail. And:</p> <pre><code>GET /mail/sent?to=110 (like applying a 'filter' to /mail/sent) OR GET /mail/sent/110 (clean URL) </code></pre> <p>returns mail sent to 110.</p>
    singulars
    1. This table or related slice is empty.
    1. POREST API design - querying mail data - which poison to choose?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USArjunShankar
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POREST API design - querying mail data - which poison to choose?
      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. VTAcceptedByOriginator
    1. COthanks for your answer. i think we will choose one of the links provied.
      singulars
      1. PO
      1. USMarcel
 

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