Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I was a bit confused by your question, so I'll try to be as comprehensive as possible and hopefully I'll have hit on an answer you need =P.</p> <blockquote> <p>I often find that the desired data is the combination of a view across multiple resources. Would you expect the client to combine them, or provide an API that does the combination for the client?</p> </blockquote> <p>In a true RESTful environment all cross-sectional views of data would be done by the server, not by the client. </p> <p>The primary reason for a RESTful design is allow access to the CRUD model (<em>create</em>, <em>read</em>, <em>update</em>, <em>delete</em>) by way of using standard HTTP verbs (e.g. <code>GET</code>, <code>POST</code>, <code>PUT</code>, <code>DELETE</code>). Storing the returns of these methods in some sort of session or cookie or otherwise external method (e.g. "give me data for bob", "give me data on businesses", "give me data from my first two queries") goes above and beyond the REST methodology. </p> <p>The way you'll want to leverage RESTful development is to find ways of combining resources in meaningful ways so as to provide a RESTful environment where the method calls are consistent; <code>GET</code> reads data, <code>POST</code> creates data, <code>PUT</code> updates data, <code>DELETE</code> deletes data). </p> <p>So if you wanted to do something like Steps 1 through 4 I'd recommend something like:</p> <pre><code>GET /user/{userID}/organizations --&gt; {return all affiliated organizations} GET /user/{userID}/events --&gt; {return all events associated with userID} GET /organizations/{organization}/events --&gt; {returns all eventID's assoc. with organization} GET /user/{userID}/savedevents --&gt; {return all eventID's userID saved to their profile} GET /events/?eventID=(15,16,20,35,36) --&gt; {return all of the events details for those eventID's} GET /events/{eventID}--&gt; {return events details for {eventID}} </code></pre> <p>Whereas you might also have:</p> <pre><code>GET /events/ --&gt; {return a complete listing of all event ID's} GET /events/{userID} --&gt; {return all events userID is associated with} POST /event/ --&gt; {create a new event - ID is assigned by the server} POST /user/ --&gt; {create a new user - ID is assigned by the server} PUT /user/{userID} --&gt; {update/modify user information} </code></pre> <p>Then if you want cross-sectional slices of information, you would have a named resource for the cross section (else pass it as arguments). Be explicit with your resources (Random FYI, name your resources as nouns only - not verbs).</p> <p>You also asked: </p> <blockquote> <p>To explain further. My hesitation is because I can see how /organizations/123/events is a clean resource; if is identical to saying /events?organizations=123, i.e. "give me resource events where organizations=123". Same for /user/100/organizations.</p> </blockquote> <p>Essentially both the <code>named resourced</code> and the <code>resource + argument</code> method can provide the same information. Typically I have seen RESTful design API call for arguments only when an important delineation is required (range requests, date requests, some REALLY small unit of data, etc.). If you have some higher-order grouping of data that <strong>CAN BE</strong> parsed/introspected further then it's a named resource. In your example, I'd have it both API calls, as the RESTful spec calls for providing data via multiple paths and by way of using the established HTTP methods. However, I'd also expand a bit...</p> <pre><code>/events?organizations=123 --&gt; {return the eventID's associated with org=123} /organizations/123/events --&gt; {return event DETAILS for events associated with org=123} </code></pre> <p>Have a read/go at this, by <a href="http://info.apigee.com/Portals/62317/docs/web%20api.pdf" rel="nofollow">Apigee</a></p>
 

Querying!

 
Guidance

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