June 19, 2007
Observations on REST and Contracts
I thought I has this RESTful web services thing figured out, but following one of the threads on the Yahoo group on Service-Oriented Architecture I came to the conclusion that maybe I don't.
Steve Jones tried to see if he understands REST by giving an example and that example was corrected by Anne Thomas Manes (a research director with the Burton Group which recently stated that the future of SOA is REST). Here are the examples from the above mentioned thread:
POST http://example.org/customer HTTP message body contains a representation of "anne" server creates a subordinate resource called http://example.org/customer/anne GET http://example.org/customer/anne returns a representation of "anne" GET http://example.org/customer/personByName?name=anne returns a representation of "anne" or perhaps returns the URI of the "anne" resource or perhaps returns a list of URIs of all people named "anne" might also be specified more simply as GET http://example.org/customer?name=anne GET http://example.org/customer/personByAge?age=27 returns a list of URIs of people whose age is 27 or perhaps returns a collection of representations of all people aged 27 might also be specified more simply as GET http://example.org/customer?age=27 PUT http://example.org/customer/anne HTTP message body contains a representation of "anne" either creates a new resource called "anne" (if none exists) or replaces the existing "anne" resource PUT http://example.org/company/newco HTTP message body contains a representation of "newco" either creates a new resource called "newco" (if none exists) or replaces the existing "newco" resource If you prefer the server to assign the URI you would instead say POST http://example.org/company HTTP message body contains a representation of "newco" server creates a subordinate resource called http://example.org/company/newco POST http://example.org/customer/anne?addCompany=http://example.org/company/newco this would append the newco company reference to the "anne" resource
You can see another example for what I am talking about here on Jon Udell's blog giving an example from RESTful Web Services, by Leonard Richardson and Sam Rubycovering of doing a transaction in RESTful style
If all these are indeed "legal" or "correct" RESTful interactions I have 2 observations to make First, I guess Pat Helland is right when he said "Every noun can be verbed"
since I don't see the real difference between having a contract with a
PersonsByAge request which returns a document* of Persons and a REST
request like " GET http://example.org/customer/personByAge?age=27" or even " GET http://example.org/customer?age=27".
The second observation has to do with the so called "uniform interface".
I would argue that the resources and their attributes (age=27,
name="anne") are the interface. the POST, GET etc. uniform interface
does not mean much more than the "uniform" SEND, BROADCAST interface of messaging.
Furthermore, if resources and their attributes are indeed "the interface" -- than not only does REST not have a uniform contract -- it actually has a dynamic one which changes in run-time as new resources are created -- such as the "POST http://example.org/company" which creates a new resource "http://example.org/company/newco" in the example above.
* I think it is very important for SOA to have document-oriented messages and not RPC one I'll blog in a separate post about the differences. for now it is suffice to say that the REST
hypermedia notion of returning the URIs of all the relevant persons
should also be present (one way or another) in a good document-oriented message even if you are using WS-* or plain messaging as transport.
Posted by Arnon Rotem-Gal-Oz at 01:58 AM Permalink
|
January 2008
| Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
|
1 |
2 |
3 |
4 |
5 |
| 6 |
7 |
8 |
9 |
10 |
11 |
12 |
| 13 |
14 |
15 |
16 |
17 |
18 |
19 |
| 20 |
21 |
22 |
23 |
24 |
25 |
26 |
| 27 |
28 |
29 |
30 |
31 |
|
|
January 2008
| Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
|
1 |
2 |
3 |
4 |
5 |
| 6 |
7 |
8 |
9 |
10 |
11 |
12 |
| 13 |
14 |
15 |
16 |
17 |
18 |
19 |
| 20 |
21 |
22 |
23 |
24 |
25 |
26 |
| 27 |
28 |
29 |
30 |
31 |
|
|
|