05/18/08 :: [REST] Answer to my Letter [permalink]

|

I have spent an extensive amount of time on the REST vs WS-* debate since 2003. Stefan and I were already arguing back then (I was also arguing with Jim and Savas  on SSDL). So you can imagine my excitement when Stefan, Teo and Subbu replied to my open letter. I wrote this letter after reading Roy's comment 10740 on the REST yahoo board. In this letter, I asked Stefan, Teo and Subbu to clarify how the "actions" from order management service were implemented. Stefan had defined two actions: Submit Order and Cancel Order, but had not given any explanation on how they were implemented in a RESTful way.

In particular, Stefan had made claims that:

The statelessness constraint isolates the client against changes on the server as it is not dependent on talking to the same server in two consecutive requests.

Stefan asked that I do not paraphrase what he says so I am simply going to copy and paste some sections from a 34 email thread between all of us.

The core of my argument is that you can interact with a system in two ways:

a) ask the system to do something for you (and as a result the system changes state), but you have no control over the state of the system
b) directly change the state of the system, to reflect what you think it should be

I don't want to say that one is bad and the other one is good, it is really a question of trade-off.

As I said, the problem that I have with the REST-based programming model is that somehow they eliminated "actions" from their programming model. They focused on the resource. I don't know who did that or why, it seems to me that Roy disagrees with this paradigm and that b) is not a viable approach to build loosely coupled systems.

I also provided the definition of a message from Wikipedia and asked both Stefan and Teo to explain their position with respect to this definition:

"Message passing is a form of communication used in concurrent and parallel computing, object-oriented programming, and interprocess communication, where communication is made by sending messages to recipients. In a related use of this sense of a message, in object-oriented programming languages such as Smalltalk or Java, a message is sent to an object, specifying a request for action."

Stefan replied:

I force my application semantics to adhere to the common HTTP semantics, which means that for every operation, I have to decide whether it's a derivative of PUT, POST, DELETE, or GET. POST is the one with the least meaning. So in the end, I mind end up with a mixture of mapping, some matching your alternative a), some matching b).

Teo replied:

Do you think about the possibility of using b) , but prohibit "direct"
change of the system state. Instead, hypermedia is used to guide and
control the flow of state change, to decide when a state can/cannot be
changed based on a particular application context.

So I wrote this little piece of code to illustrate how the client code of the decision service would look like:

class Decision
{
      ...
      public static boolean check(Application a)
      {
           // make a decision
      }
      public static synchronized void onApplication(Applicaiton a)
      {
          boolean decision = check(a);
          //now assuming there is two links in the Application representation
          if (decision) a.navigate(a.acceptLink());
          else a.navigate(a.rejectLink());
      }
}

I then asked Teo to clarify what he meant by: "hypermedia is used to guide and
control the flow of state change"

At that point Teo replied:

I agree with you. When I realized this issue recently, I began to
understand these action/control/navigational (or whatever we should
call them) information in hypertext documents are the public APIs.
Developers must agree on them before their applications can work
together.

Web community build & agree on these public APIs on top of Internet
Media Types.

If you notice, in atom-protocol mailing list, what they are doing most
of the time is to propose and agree on new public APIs to support new
features that most developers need. Enough momentum will push the
proposed API as published standards, e.g. RFC5023 (AtomPub), RFC5005
(Feed Paging & Archiving) etc. These RFCs helps to promote the reuse
of public APIs.. hoping for more adoption to allow more applications
to work together.

So to sum up, I had asked 3 simple questions that have never been really clarified:

Question a): how to write some client code and potentially some service code that result in transitioning (in a RESTful way) the Job Application resource into a rejected state

Answer: Teo and Stefan's responses indicate that the client code would look like the code I provided above. The actions will be encoded, in some ways, over HTTP. Teo provided a great sample on how to do this encoding with APP. Stefan declined to provide a sample, but his answer was explicit enough.

Question b):how once the lifecycle has ended, no further changes can be made to the resource

Answer: No reply were specifically provided for this question, though it looks like they would do it the normal way, by preventing an action to operate based on the state of the resource.

Question c): how can I add an operation on the job application service and demonstrate that the decision service client is isolated from this change

Answer: You can't

This discussion makes this claim totally, absolutely, definitely and forever BOGUS:

The statelessness constraint isolates the client against changes on the server as it is not dependent on talking to the same server in two consecutive requests.

Anybody who would be using it today would be misleading other people.

This discussion debunks once and for all the utopia of the uniform interface when dealing with resource-to-resource interactions. Either your interface is uniform and your are CRUDing your resources creating a terrible coupling between resources and resource consumers, either you use REST to pass messages to your resource(s), if that's the case, your interface is not uniform.

My conclusion, and it is definitive, is that REST as a programming model for resource-to-resource inter-actions brings very little compared to WS-* (considering that you are on your own for so many things that WS-* provides out of the box).

I am not here to tell you which stack to use WS-* or REST/APP. Personally I don't care, this is "on the wire", and frankly, I don't think many people care. I have expressed what I like about REST. You might also want to use this paper to help you decide which to use when. Contrary to what some have said, this comparison is fair and care to help people make passionless decisions.

REST as defined by Roy Fielding (not by the other REST community) brought us the Web. THAT REST is brilliant, I have said it many many time, let me say it one more time before I close this debate forever. I have never, a single time, attacked REST as defined by Roy.

I apologize to all members of the (other) REST community for my "rudeness". I hope they will understand that, after five years, these answers were critical to get as they impact hundreds of thousands of architects that have to deal with this very question (REST or WS-*). You will also understand that we could have had the exact same discussion last November, plain and simple.

I don't expect that the members of the REST community will advertize this post and this discussion, nor will they stop their silly comments on WS-* and SOA. This is their call, at least we know better today.

Yet, the REST vs WS-* debate is o-v-e-r. Now I understand.