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.

Thanks for the reply, I get it now.. that HATEAOS constraint was never clear to me.

But this makes me think:

The client does not make assumptions about this contract.

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 :).

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.

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.

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.

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).

IMHO The REST/SOAP layers define the public access to your application and map requests/responses to from the business layer.