A common way of designing a REST system is to recognize the resources and associate a logical hierarchy of URLs to them and perform the traditional CRUD operations by using the well-known HTTP methods (GET, POST, PUT and DELETE).
However, many systems have operations which don't quite fit into the CRUD paradigm. Say, I have a repository of
persons. And say I have an
id associated with every person which allows me to have nice URLs to each person as such:
http://example.com/persons/1This URL obviously GETs me the details pertaining to person
1. Now what if I wanted this person to
walk. I can think of 3 approaches to designing this scenario:
- Operations as resources: Which means I can have URLs such as:
talkare obviously not resources and designing it this way might be considered unRESTful(?).
- Operation as a query parameter: This leads to URLs such as:
http://example.com/persons/1?operation=talkA drawback of this approach comes to the fore if you need other parameters to perform an operation. So, for instance, if you had to specify
walk. You'll end up with URLs such as these:
http://example.com/persons/1?operation=talk&what=HelloAs you can see, with this approach you end up having resources with overloaded operations and parameters. And you have to be aware of these combinations yourself and also explain them to your users.
- Matrix URIs: Specify the operations using matrix-like URIs. With this, your URLs look as such:
http://example.com/persons/1;talkAnd you can specify the operation parameters using the traditional query string:
http://example.com/persons/1;talk?what=HelloWith this approach you have 3 distinct ways of representing 3 different things - slashes (
/) for hierarchical resources, semi-colons(
;) for operations and query strings (
?param1=val1¶m2=val2) for parameters.
Many questions. Any answers?