I gave a presentation to the Web Services Architecture WG last week. It focuses on comparing REST with other “distributed object” styles, specifically tuple spaces, OO RPC, and email.
The pushback I got on it at the meeting was “But REST is for humans!” (wrong). The question I posed at the end never got answered, but is crying out for one I’d say;
What about a uniform interface makes it unsuitable for machine processing?
Paul Prescod responds to Adam Bosworth’s “One Fell Swoop” article. Right on again. But there was something else in there that I felt needed some clarification; application state.
Adam writes;
[…]Thinking of the Web servers as “objects” is an extremely bad idea. Objects are repositories of state. Conversations with them are by definition not stateless.[…]
There, Adam appears to confuse object state and application state. The former, object state, refers to the state held by the object, in the “behaviour, state, identity” sense of the word. For example, the state of the current weather in Ottawa is 11 degrees C.
“Application state” refers to the progression of the system during the execution of the application, more commonly (and less confusingly, IMO) referred to as “session state”. In the weather example, “session state” is held entirely by the client as the weather service need not remember anything about my invocation in order to serve it the next time (though that’s obviously a weak example). Any stateless interaction means that application state is maintained by the initiator of that interaction. Any stateful interaction means that application state is, at least in part, maintained by the recipient; this can range from part initiator, part recipient with HTTP+cookies, or full-recipient state in a remote session architecture like VNC.
Just noticed Simon’s reference to his SOAP SMTP binding spec. Section 6, “Security Considerations” says “This should introduce no new security considerations.”. Bzzt! 8-)
Consider that by requiring the SOAP response in a new email, rather than using the SMTP response as the response, you’re requiring that any deployed implementation of software conforming to this specification, include an automated responder where none was previously. That is, what was once a safe “input only” protocol (SMTP), has been turned into a request/response protocol. There’s oodles of new security considerations to consider because of that.
So while at the Web Services Architecture WG face-to-face, I was chatting with an unnamed attendee about the eventual “Judgement Day” for Web services; the day when the TAG, and/or TimBL will decide whether or not Web services have anything to do with the Web. This person, who is very likable and definitely well respected in the Web services space, said that if Web services get kicked out of the W3C, their company would leave the W3C.
Hello?! Wouldn’t you think that a more reasonable response would be something like “Well, I suppose we’d have to navel gaze for a while and understand what this means. I mean, the Web is a good thing, right? And if we’re doing things that don’t respect or reuse the principles that made it work so well, we should fix that I think.” Wishful thinking, I know. Sigh.
Hey, I’m a CXO of my own company; CTO, specifically
For those who want to understand the issue Mark has with SOAP, he objects to the string “doGoogleSearch” in this example. FWIW, I don’t see how this is any different, architecturally, than hidden controls in HTML.
It isn’t any different than hidden controls, but I wouldn’t use hidden controls either. I’d just POST the data “q=foo” to whatever URI the POST form told me too. No need to understand what “doGoogleSearch” means, because the context in which the POST operation is to be interpreted by the server, is provided entirely by the URI to which I’m POSTing.
Now it turns out that the Google API has a limit of a 1,000 queries per day. This means that the 1,001st query will not have the same result as the 1,000th query. The query itself has a (GASP!) side effect. It is most decidedly not idempotent. So what do you do? Call back the Hobbits and recode to use POST, or do you make the pragmatic decision to slightly bend the rules a bit?
Well, first of all, that part of 2116 that you referred to earlier in your blog (presumably you meant 9.1.1 not 9.1.2) says “SHOULD NOT”, not “MUST NOT”. The reason this is so, is because unsafe GETs won’t break the Web; web page counters demonstrated that. What will break the Web is if people who click on a URI get blamed for causing the side-effect, as 9.1.1 points out when it says “The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.”. Also, it’s not a fundamental axiom, in the same way that a uniform interface is – it’s derivate (though lots of other important principles are too).
But with that said, your example is an excellent one, because clearly a counter such as the one you describe would be “blaming” the user for bumping it up by one. So IMO, no, this service should not use GET, at least for those queries. It should be bootstrapped with GET though, so that you GET the HTML form, but the form results should be POSTed back.
Also, in case you were going to suggest that this somehow makes the Google API “ok” because it uses POST, it should be noted that it doesn’t use POST, it tunnels through it. A client needs to know more than just the URI, the form structure, and the POST method. It needs to know what the string “doGoogleSearch” means.
And as for RSS, I welcome any suggestions for a blogging tool/service that provides free RSS feeds and lets me edit from a browser (something that Dave Winer seems dead set against providing – or at least he was in the past).
Sometimes I see signs of smart folks figuring out how to do Web services properly, and I feel a glimmer of hope that the industry may not be wasting hundreds of millions of dollars with SOAP and WSDL. Then I see stuff like this, and I realize, nope, it’s going to hell – specifically this part;
Bergandi: With a wizard-based environment within the SOAPswitch. The SOAPswitch itself has self-discovery capabilities. It has the ability to, in the example I gave you, inquire into the metadata of what the Siebel system looks like; discover what business objects are available and what methods are available against those business objects; and then, based upon that, in a very, very simple way, generate all the SOAP that’s required for communication.
Internet-scale distributed computing just ain’t that easy, folks, sorry.
According to Jon Udell, extremism is dead. How silly! Sometimes, whether you know it or not, the truth is not shades of grey that requires finding a middle ground, it’s boolean. Take REST vs. Web services, for example. REST is a simply a superior architecture by all important measures, than what people know to be Web services (the definition’s so fuzzy, it’s hard to pin down a specific one to argue against). End of story. And not just in the “oh yah, I guess I’d prefer REST” sense, but in the “Web services will fail to achieve their goal, and ultimately be discarded” sense. Just because someone hasn’t done the homework necessary to properly evaluate REST, does not change this.
Extremism will live on, so long as there is right and wrong.
In the words of Henry Hazlitt (though the snippet starts slightly out-of-context);
“We Haven’t Been Good Enough”
I am going to give what is no doubt a terribly oversimplified answer to that question. In the first place, we are almost hopelessly outnumbered. Our voices are simply drowned out in the general tumult and clamor. But there is another reason. And this is hard to say, above all to an audience of this sort, which contains some of the most brilliant writers and minds in the fields of economics, of jurisprudence, of politics, not only of this age but of any age. But the hard thing must be said that, collectively, we just haven’t been good enough. We haven’t convinced the majority. Is this because the majority just won’t listen to reason? I am enough of an optimist, and I have enough faith in human nature, to believe that people will listen to reason if they are convinced that it is reason. Somewhere, there must be some missing argument, something that we haven’t seen clearly enough, or said clearly enough, or, perhaps, just not said often enough.
A minority is in a very awkward position. The individuals in it can’t afford to be just as good as the individuals in the majority. If they hope to convert the majority they have to be much better; and the smaller the minority, the better they have to be. They have to think better. They have to know more. They have to write better. They have to have better controversial manners. Above all, they have to have far more courage. And they have to be infinitely patient.
(thanks to Roger Costello for the pointer)