I’m a bit of a sceptic when it comes to REST and the SOAP vs REST “debate”. There seems to be a tinge of hatred of corporate IT and dogmatic promotion of niche programming languages. There has been quite a lot of REST-o-ranting on the topic and I am not going to go there now.
REST does interest me in the influence it has on service design; indeed I have been a little worried that a lot of alleged SOA is not as loosely coupled as the philosophers would like and that, even when using document-style (rather than rpc style) SOAP, it is too easy to be led astray into, for example: OO thinking, CRUD. REST is both attractive in lending itself to loose coupling and unattractive in drawing one towards class-oriented design rather than business process oriented design so I thought I would have an attempt at a REST approach to IMS Enterprise Services v1. Scott Wilson had a look at a “REST-style” approach to IMS Enterprise Services some time ago but this isn’t in the same style that I look at, which I think is more fundamentalist resource-centric. I don’t think either of us is actually saying that real implementations of IMS Enterprise would never want to use the WS-* stack; it offers a heap of valuable heavy-weight capabilities.
My first cut is available in PDF:
You’ve got PUT and POST the wrong way round
CreateByProxy is more in keeping than Create. POST actions involve the service creating a new URL, which is usually not something the client has a say in.
Both creates and updates ought to return the new/updated object, as often the service will fill in additional stuff like the identifier/URL and other service-created metadata like creation date – its good to have this echoed back on success.
When I did the initial REST thing it was on the assumption that people would only want to read data via a REST-style interface, so its really more xml-http than proper REST to optimize the query aspects. As it turns out, projects implementing ES via REST wanted the full CRUD set.
I had a very interesting debate last month with a chap from LogicaCMG – its paradoxical that the more loosely-coupled and abstracted (in theory) WS approach is only really found in tightly-managed situations (intra-enterprise), whereas the more resource-bound, tightly-coupled (in theory) REST approach is favoured for wide distribution.
I think a possible explanation is that the combination of scalability and simplicity NFRs have priority over the purely functional aspects of the approaches (verbs vs nouns as primary action identifiers). If SOA protocols had B2C scalability and end-developer simplicity, instead of spec bloat and ghastly complicated frameworks, maybe we’d have been seeing SOA all over the place instead of REST. However, we don’t live in that universe!
Ah the PUT vs POST pitfall. I think you are right that createByProxy should be a POST but I’ll stick with PUT for create.
The update and replace operations use PUT and POST to signal the different semantics: for replace, it seems clear that PUT is appropriate since the client is sending the entire new person record for a given URL. POST seemed right for the update since there is server processing to determine the end effect on the identified person “resource”. I do accept, however that the client is providing the URL and that by a reading of HTTP spec, POST doesn’t sound quite kosher.
I used a similar logic for the changeIdentifier operation, although I actually have a bit of a problem with this operation anyway since the identifier being changed is really just a surrogate primary key and shouldn’t be used as an identifying attribute outside the interoperating systems.