Databases
StackOverflow2013
Postsdbo
POREST API DESIGN - Getting a resource through REST with different parameters but same url pattern
Body
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POREST API DESIGN - Getting a resource through REST with different parameters but same url pattern
    text
    copied!<p>I have a question related to REST url design. I found some relevant posts here: <a href="https://stackoverflow.com/questions/16273390/different-restful-representations-of-the-same-resource">Different RESTful representations of the same resource</a> and here: <a href="https://stackoverflow.com/questions/11104466/restful-url-to-get-resource-by-different-fields">RESTful url to GET resource by different fields</a> but the responses are not quite clear on what the best practices are and why. Here's an example.</p> <p>I have REST urls for representing "users" resource. I can GET a user with an id or with an email address but the URL representation remains the same for both. Going through a lot of blogs and books I see that people have been doing this in many different ways. For example</p> <p>read this practice in a book and somewhere on stackoverflow (I can't seem to find the link again)</p> <pre><code>GET /users/id={id} GET /users/email={email} </code></pre> <p>read this practice on a lot of blogs</p> <pre><code>GET /users/{id} GET /users/email/{email} </code></pre> <p>Query params are normally used for filtering the results of the resources represented by the url, but I have seen this practice being used as well</p> <pre><code>GET /users?id={id} GET /users?email={email} </code></pre> <p>My question is, out of all these practices, which one would make the most sense to developers consuming the apis and why? I believe there are no rules set in stone when it comes to REST url designs and naming conventions, but I just wanted to know which route I should take to help developers better understand the apis.</p> <p>All help appreciated !</p>
 

Querying!

 
Guidance
An individual column

Larger individual text columns get their own page to allow for proper reading.

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