At last night’s post-dinner speaker panel we pretty much heard from the audience and from the other panelists that things in the XML and web services world still kind of suck. An outsider looking in would certaintly wonder if anything worked all.
Tim is pointing out that things do actually work pretty well. I will do the same in my talk later today.
XML over HTTP vs. SOAP, the difference is not all that big, as once demo’ed by Sam Ruby. If we do things right then we can be ready for the future, and leverage the protocols. The cost to use SOAP is just an envelope and a body. The technologies overlap 98%. The tools do not overlap.
Some advice from his step-father: “Make it easy for people to pay you.”
His brother can build a house with a broadaxe and a forest, but that doesn’t mean its the best way to do it.
SOAP is the extensibility point, lots of it there for the future — addressability, security, etc.
In REST, the URI alone specifies what is to be done. In SOAP it is the action URI, or is it the action URI + message + endpoint? All of these can influence the interpretation of what is supposed to happen. Where are the semantics?
Establish contracts for services before starting on the implementation. Toolkit is an implementation detail. None of the schema languages are adequate yet.
People choose REST because it is easy, not because they believe in REST or in Fielding’s thesis.
Toolkits have to provide easy access to raw XML, and easy access to the wire. Consume XML in a stream for big documents (e.g. MSDN). Buffering and using a DOM can be very painful for big documents. Pay only for what you need.
With versioning, description is in the eye of the beholder.
Interoperability — a floor (base to build on), a ceiling (some limits), four walls, and no doors (no options). Tools don’t support much in the way of choice. Subsetting schema is like this.
Hope springs eternal, we are sooooo close. Just need reliable messaging and MTOM.