<[EMAIL PROTECTED]> wrote:
>
> > As we've been discussing, in practical implementations of REST the
> > client and server are extremely tightly coupled because the
> > representations cannot change without you rewriting your client or
> > server application code.
>
> This is a curious statement. The most practical implementation of REST
> has to be the web. Look at all the variety of servers, and no client
> is hardwaired for any of them. The SOAP interfaces I have seen are
> infinitely more tightly coupled than this.
>
Ah, the old canard about the web being an example of a truly successful
program-to-program communication system! Not true.
At the risk of repeating myself, there are probably three main reasons
the web "works" so successfully. These are: massive asymmetry with
many more clients than servers, predominantly read-only access and the
fact the the browser and origin server are actually intermediaries not
endpoints (the true endpoints being human beings).
It may be interesting to look at how poorly the web works from a
program-to-program point of view. Consider HTML, for example. As a
content provider or browser developer, what version do you support,
what does it mean and how do you expect it to be formatted or
understood? Presently, we have a complete mess where browsers
implement a kind of "tag soup" form of differing versions of HTML/XHTML
where the behaviour is in many cases dependent on the particular
browser. Browsers try madly to keep up by implementing "DOCTYPE
switching" and similar techniques to try and figure out what the
content providers are really trying to say.
Similarly with CSS. The behaviour of CSS within browsers is wildly
different and content providers are forever creating new "CSS hacks" to
try and enforce any kind of consistent behaviour. Unfortunately, this
is a losing battle, particularly as newer browsers tend to see
the "hacks" for what they are and don't process them in the same old
erroneous way as earlier browsers.
What do you do with images? Can you use PNG format? With transparent
pixels? Why knows what the browser will do with your image. Also how
is the progress of SVG support being rolled out? Does your browser
support it yet? As a content provider, is it worth generating
information in these formats? Who will be able to view it?
Our colleagues in the web world are really struggling to get a handle
on this mess. In the meantime, there exists considerable "tight
coupling" between most web sites and particular browser implementations.
Of course to some extent you can get away with all this "sloppiness"
when your software is just an intermediary and a human will [hopefully]
understand what's going on, figure things out from mis-aligned and mis-
presented information, identify missing or ambiguous information and
generally sort everything out for you.
But our "dumb" programs aren't anything like as smart. In fact, the
world of business and especially commercial transactions require
quite "tight coupling" in the form of precise information
understanding. That is, commercial transactions need to understand
exactly what is being said during a message exchange with no
ambiguity. Don't you always read the "small print" before signing a
contract?
Imagine if certain browsers processed dollar e-commerce amounts as
loosely as they do CSS pixel positioning? Some customers might be
charged $100.00 and others £1000.00 for the same item (or they may
think so), with no way to tell. What, is that customer called "Mark
Baker" from Canada? Did you mean the one in Ottowa or one of the
several in Toronto? Hey, we're loosely coupled so it doesn't matter
exactly who we charge as long as we identify someone, eh?
In the real world, accuracy counts, and in many ways that goes against
our "loose coupling" goal.
No, I think that we still have some way to go in order to realise the
true issues and benefits of "loose coupling" when it comes to program-
to-program interactions. I just wish we could move on from the rather
sterile SOAP vs. REST debate, with each side (esp. the latter)
proclaiming "victory" onto what we need to do to solve the real issues
involved...
-Mike.
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
