Databases
StackOverflow2013
Postsdbo
POSending multiples parameters using GET request
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POSending multiples parameters using GET request
    primarykey
    data
    text
    <p>Let's say I have a resource with this URI:</p> <pre><code>/predictions?route=A&amp;stop=AAB2&amp;direction=forward&amp;type=regular&amp;currenttime=12:34 </code></pre> <p>That URI gives me the next arrival time for the <code>forward</code> bus stop named <code>AAB2</code> of route <code>A</code> in a <code>regular</code> day (Monday-Friday). I think this is well designed but <strong>just for one</strong> resource at a time.</p> <p>The problem: I want to get N predictions with differents parameters; obviously I don't want to make N requests, so my question is: how can I achieve this?</p> <p>Maybe I'm wrong but I don't think this would be a good solution:</p> <pre><code>/predictions?route=A&amp;stop=AAB2&amp;direction=forward&amp;type=regular&amp;currenttime=12:34&amp;route=B&amp;stop=BBCC2&amp;direction=forward&amp;type=holidays&amp;currenttime=23:34 </code></pre> <p>neither this</p> <pre><code>/predictions?route=A,B&amp;stop=AAB2,BBCC2&amp;direction=forward,forward&amp;type=regular,holidays&amp;currenttime=12:34,23:48 </code></pre> <p>Can I send JSON objects through URL?</p> <p>The client is written in Java (Android) and the server is in PHP (using Slim framework).</p> <p><strong>Edit</strong></p> <p>As Palpatim suggested, this is another approach:</p> <p>For a single time arrival prediction</p> <pre><code>/routes/A/stops/AAB2?direction=forward&amp;type=regular&amp;currenttime=12:34 </code></pre> <p>For multiple time arrival predictions (for all bus stops of route A)</p> <pre><code>/routes/A/stops?direction=forward&amp;type=regular&amp;currenttime=12:34 </code></pre> <p>That seems more "RESTful" to me. But what if I want multiple predictions for different routes? (e.g. I want a prediction for the stop AAB2 of route A and stop BBCC of route B ... with the URI's above I still have to do two requests instead of one.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USEnrique Marcos
    1. USEnrique Marcos
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    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. COConsider the discussions here http://stackoverflow.com/questions/5020704/how-to-design-restful-search-filtering and here http://stackoverflow.com/questions/207477/restful-url-design-for-search The basic question I'd ask yourself is "Am I defining my resource correctly?" Your model looks more route-centric than prediction-centric.
      singulars
      1. POSending multiples parameters using GET request
      1. USPalpatim
    2. COGreat links. But I'm still a bit confused. I have also URI's like this: `/routes/A/stops/AAB2` (this one shows info about a particular bus stop). Why `predictions` should not be a resource?
      singulars
      1. POSending multiples parameters using GET request
      1. USEnrique Marcos
    3. COAccording to my understanding of RESTful architecture, there should be one canonical way of addressing a resource, and a resource is typically a single, concrete thing: a person, or a document, etc. A "prediction" is essentially returning a stop: the next stop along a route, given the associated filter constraints. A different way of considering the `/prediction` API is `/routes/A/stops?prev=AAB2&direction=forward...`. That is, a filter on the list of stops, based on criteria like "what direction" and "what time" and "what previous stop"? In that model, a "prediction" is a canned search view.
      singulars
      1. POSending multiples parameters using GET request
      1. USPalpatim
 

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