Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Creating a resource URI in a hierarchical fashion has the benefit that you won't have any id collisions. Your alternative version <code>http://test:password@site.com/test/</code> could become problematic if you add another resource type (e.g. Role) with id <code>test</code>. You will have to ensure that your IDs are unique over all resource types and not only for a specific type. In addition: It's no longer clear, whether your resource URI points to an User or a Role. </p> <p>And while it is not really required for REST it's one of the naming things that makes it easier for us humans to think about a REST API: "User Resources can be found in URIs containing the "users" label seems just so normal. REST itself is actually URI agnostic so it really shouldn't matter. But if you want to use meaningful (human-readable) URIs I would say</p> <pre><code>GET http://test:password@site.com/users/ </code></pre> <p>will return all users.</p> <pre><code>POST http://test:password@site.com/users/ </code></pre> <p>will create a new User and a new resource with an URI.</p> <pre><code>PUT http://test:password@site.com/users/test </code></pre> <p>will change the User resource identified with this URI and to fulfil reasonable expectations you should be able to get this user resource as</p> <pre><code>GET http://test:password@site.com/users/test </code></pre> <p>Last thing to consider: the authorised user might want to access the user resource for a different user (as unlikely as this scenario might currently seem):</p> <pre><code>GET http://another:password@site.com/users/test </code></pre>
 

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