As I was debating some comments with JJ over the weekend on a paper that I am writing on describing RESTful applications, the question on composition came up. In particular, who is composing your app? The server? Or the client? The context of our discuss was the difference between describing the contract of a RESTful application vs describing that of a web service (the SOAP kind) using WSDL.
In the SOAP-land, services express their interface via WSDL documents. A WSDL is nothing but a group of message exchange patterns, expressed in a context-free manner. Each pattern accomplishes some discrete function, which may or may not be interesting and useful on its own. Clients combine various message exchange patterns into an application to accomplish something of value. For instance, an app doing implementing some HR functions may be talking to some payroll services. Only the client knows the context in which it is using those payroll services. As far as the payroll service is concerned, it is just “message in and, optionally, message out”. It does not know what the client is trying to accomplish.
In this model, how does the client know how to compose such services into its application? In particular, how does it know whether it is okay to send a particular message “M” to a service “A” before sending message “N” to a service “B”? WSDL does not have this info. So, it has to make some assumptions either on its own, or rely some composition framework or language (like BPEL). In either case, the service does not have much to say.
In the REST-land, resources rely on the uniform interface, media types, and links to express the contract. More interestingly, the links that the server provides inform the client of what it can do subsequently. That is, the links in a representation let the server incrementally express the interface between the client and the resources it is interacting with.
In this model, the contract is contextual. The client does not make assumptions about this contract. Nor does it need an external composition framework. If it finds some links with some known relations, it means that it can do certain things. If, at a later stage, it does not find those links, it means that it can not do those things.
This is an important difference worth calling out, as it has a number of consequences:
- The same client/server code can not support both REST and WS-*. Code sharing may be possible at lower levels, but not at the application level. This is where I don’t agree with Alan Dean’s statement that a system can compose both REST and WS-*. I hope I am interpreting his statement right. The differences between client-side and server-side processing are significant enough to demand code isolation.
- A RESTful server can change or finetune the contract at runtime. So, the client must be prepared to accept changes in the workflow at runtime.
- A RESTful server can move resources around or even upgrade resources in a compatible manner at runtime, and a RESTful client will not even notice such changes.
Thanks to JJ for his time.
{ 10 comments… read them below or add one }
I do believe that REST and WS-* are not mutually exclusive at a system level.
Take the example of the third diagram in my post “On RESTful Basket State” which shows a client composing two services: basket persistence and checkout. There is no reason why the client could not use a WS-* service to persist the basket. Would I advocate it? Probably not, but there may be times when it may make sense (perhaps the WS-* service already exists and you are simply leveraging the work of others). Decoupling the two services allows different technologies to be employed, if desired (just as the client might choose to employ a local database using SQL to persist the state).
What I would agree with you on (and I assume it is this to which you refer) is that within a logical service, mixing REST and WS-* would not be clever. I certainly didn’t mean to imply that was a good idea at all.
I think I misunderstood your slide. I thought you were referring to using the same code base to do both. Thanks for explaining.
I definitely think you can use the same code base to support both REST and SOAP abstractions. The abstractions would be different (i.e resources vs services) but there is no reason why you can’t define a business layer in your architcture and then layer a thin REST layer to provide a resource-oriented view or a SOAP layer to provide a service oriented view.
IMHO The REST/SOAP layers define the public access to your application and map requests/responses to from the business layer.
Is there anything that can't be fixed by layering ;)
@Jim and @Subbu:
then what is the point of this whole discussion (REST vs WS-*) if the targeted code is the same? Doesn’t it boil down to a marshaling problem? No Sane developer would keep writing boiler plate code be it REST/HTTP based or WS-* based.
The question is what are the patterns of interaction of “connected systems”, I contend that this is the real question, this is what developers need. We have concepts such as Service, Resource, Event that seem (and are) relevant to building connected systems. Who can believe that Resource is enough, or Service is enough or Event is enough?
Look at the Oslo team view of REST: http://www.ebpml.org/blog/149.htm (last figure, the Echo “service”), people are obviously confused about all these concepts, and I mean, even grand pumbas of industry can’t get it right. This is just one example, Roy recently complained about everybody on the planet claiming they are RESTful.
@Jim
>> IMHO The REST/SOAP layers define the public access…
IMHO, this is a mistake to think this way. The problem we have today is that there is a tremendous mismatch between traditional application models and what is required to build “connected systems”. Resource orientation, Service Orientation and Event Orientation are all important and complementary concepts to build connected systems. It is a mistake to think that using SOAP or HTTP to expose traditional application model semantics is going to cut it. You need to rethink the application model and the assembly model (assembly as in connected system). I have written a book about it that can be downloaded for free on InfoQ (Composite Software Construction).
@JJ
You are right that the code is not the same, and my comment to @Jim thick enough layering may shield the differences, but I would not do that.
Regarding your comment about Oslo, I can’t agree more.
Linking is about connectedness, and when applications limit representations to plain data, they are completely ignoring the connected nature.
I have little experience with REST, but your approach seems over-designed to me ..
It seems to me that you’re taking the “hypermedia as the engine of application state” a little too far, and it’s looking like “hypermedia as the engine of application workflow and business process”. If I understood well, the resources being exchanged with the server are the workflow descriptions themselves, not just the resources like Products, Baskets, etc. I think an architecture as generic as you describe would be very interesting in some application niches, but not a necessary condition for some system to be considered RESTful.
I believe the e-commerce basket system described by Alan Dean is already RESTful, since it is based on exchanging resource representations, even tough it doesn’t define the workflow.
@Tiago:
The key point here is to note that a server app can use hypermedia to dynamically tie resources together. If you look at the web, it is precisely this mechanism that is used in HTML. That isn’t a niche area.
Also note that the “state” in HATEAOS refers to the state of the application, viz., where in the flow the client is, and what possible things it can do.
Describing data as representation may be good enough in some cases, but such a model assumes two things – (a) that all URIs are prepublished, and (b) a client can submit a request for any resource (at a URI) at any time in a completely stateless manner. But most applications are stateful, and linking lets you capture that state.
@subbu
Thanks for the reply, I get it now.. that HATEAOS constraint was never clear to me.
But this makes me think:
In my understanding, this means that a client interface must the generated at runtime based on the contract exposed by the server. But what if I want to (or need to) develop a rich client that indeed makes assumptions about the contract? (for example, by not letting the user edit some input fields). Would this be a violation on the REST principles?
I fell that making the client dependent of this contract at runtime makes the system more tightly coupled. Or maybe I’m missing the point again :).
@Tiago
Not necessarily. Suppose a client has implemented functionality to “edit” a resource. That is, it knows how to submit a PUT request to the server. The dynamic part is just about whether the client is able to find an “edit” link or not. If it does not find a link in the representation, it can disable that function.
{ 1 trackback }