Reputation: 3132
For example, which of these (if any) is most RESTful? Why??
/employees/id/45
/employees/?id=45
/employees/45
Thanks!
Upvotes: 2
Views: 1985
Reputation: 10991
The correct answer to your question, which one (if any) is most RESTful, is that they are all equally RESTful. This is because URIs are opaque to a REST client as a consequence of HATEOAS, though they should be 'hackable' to a human reader. When you click a link in a web browser, the URI is (or at least ought to be) hidden behind some more meaningful (semantic) text, such as earlier in this paragraph. It does not matter to you as a urse of the site what the address in the address bar is, unless you want to start exploring by chopping bits off the URI or adding/replacing your own terms.
If your question was intended to cover more the URI design or API design aspect than what is/is not RESTful, then please expand the question to discuss your API more.
Upvotes: 0
Reputation: 13377
If you'll almost always be GETting employees based on an ID, I'd just use
/employees/45
Are you planning on supporting employee lookup based on multiple properties? If so, go with:
/employees/id/45
Since you can then add
/employees/dob/19940604
Really, I think you'd want to have:
/employee/45
Which always returns a single instance of an employee (note that employee is singular), and then some URL which returns an EmployeeCollection, based on criteria:
/employees/dob/19940604
/employees/lastname/crumbling
Upvotes: 3
Reputation: 2160
For a REST API item type employees is directly addressed. It is implied that the entity is uniquely identified with id. hence, most appropriate URL is
/employees/45
Though the other option
/employees/?id=45
is equally valid.
The main aspect is that GET/PUT/POST should be used appropriately against the same URL for respective API.
Upvotes: 1