REST vs ?

It is nice to read the blogs that I have missed for almost two months and write something on my own. I found many guys raised another tons of discussion about REST and web services. As I remember, they compared REST and SOAP at first, then REST and web services, and then REST and SOA. I do not know what is the next to be compared with REST.

Many like to predict the technical changes in the coming year. In his post, Carlos predicted that

"WS-* and its corresponding specifications like SOAP and WSDL will be declared dead by year end."

It is interesting that the technology is considered hopeless when the developers of SOAP engines are struggling to improve its performance. What I hope is by the end of 2007 the debate about REST vs ? will stop. Obviously, the "dead of web services" cannot assure that.

Mark Nottingham listed the "real and imagined issues" here. I agree with most of them. However, I still think that the following is really an issue when interpreting the REST as the Web technological style.

"False Choice: Machines vs. People
There’s an insistence from some quarters that somehow, HTTP and REST are only good for people sitting behind browsers. I think that this has been solidly and obviously disproven, and find it difficult to believe that such continued, vigorous assertions are anything other than FUD. *shrug*"

Why? It is because "one of the deeper REST constraints is using hypertext as the engine of application state". The Web is the space of information, or the virtual state machine of web pages. Mark Baker believes "the Web, since its inception, has always been about services, and therefore that “Web services” are redundant." Of course, that depends on how to define the "service". The success of Web results from its architecture, REST, or more concretely, client-server, request-response messaging, and loose-coupling by HTML, XML, and widely accepted scripts. To make all this happen, the browsers are the heroes in the background. The browsers are the agents working for people. People with the browsers trigger the state transfer of the Web as a virtual state machine. In the service scenarios, every service can trigger the state transfer of the virtual state machine of services. If a long long URL with all the request information encoded inside is tolerant and no MEP's other than request-response are needed, fine, let's just call it "services" not "web services", and make it just like a web page.