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.

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!