Well, yes, once again.
To illustrate why I believe a RESTful application design is different not only in implementation details, I’ve created these two diagrams:
Service-oriented Design
In this model, there will be very few services, each of them exposing a number of operations. Every service is different (has its own interface); the service itself does represent any entity (something which has a logical identity). Instead, some information to identify entities is passed as parameters or, if your prefer, information within the documents.
Resource-oriented (REST) Design
In a RESTful architecture, the key resources are identified; these can be entities, collections, or anything else the designer seems worthy of having its own URI. The standard methods — in this case, the HTTP verbs — are mapped to resource-specific semantics. All resources implement the same (uniform) interface. Not shown in the simplistic diagram is the dimension of content-types, which allows for different representations of resources (e.g. in both XML, HTML, and plain text), as well as the possibility of links to resources in resource representations. Use your imagination — e.g. the GET on /customer/4711 would return a document that contains a link to a specific /order/xyz.
Yeah, I like it. One thing I’d consider is not mentioning http at all. I’d talk about CRUD instead maybe or whatever David@Rails had in his presentation (World of Resources) recently. This would allow people to see the design differences without having their minds corrupted by their (wrong?) understanding of what HTTP is.
i.e. Let’s keep it as pure as possible.
Best,
Dan.