Lists Home |
Date Index |
2/8/2002 5:23:41 AM, Paul Prescod <email@example.com> wrote:
>I offer an alternative that will end the madness and stop the
>escalation. Use HTTP because it is pragmatic. Also use it *as HTTP* so
>that it works with, not against the firewall software and firewall
>administrators. Be completely open and honest about what you are doing.
>Make each message as visible as possible to the firewall. (and invisible
>and opaque to hackers)
I'm beginning to see the point now. Perhaps I'm too dense to get the subtleties
here: does this point of view tend to invalidate the SOAP/WSDL paradigm or just
suggest that the RPC message exchange pattern should probably not be implemented
over HTTP? Of course, this MEP accounts for about 99% of the actual use of SOAP
in practice, AFAIK ...and 100% of XML-RPC, so this isn't a "big guys vs little
guys" or "simple vs complex" cleavage.
Sean McGrath has a nice article on this subject
http://www.itworld.com/nl/xml_prac/01312002/ "Having read the dissertation, I'm
having trouble reconciling this "Web as API" view with the REST architecture. Is
it feasible to implement the Web services vision on top of the Web without
violating the principles in REST, which made the Web work in the first place?"
So, we apparently agree that REST raises issues that Web Services need to
address. So how do people think the issues will be resolved? In what concrete,
pragmatic way will the contradiction between REST and RPC over HTTP potentially
cause the Web Services bubble to burst?
To put it differently, Sean says 'I'm having trouble reconciling this "Web as
API" view with the REST architecture.' OK, I do too, but he notes that cookies
violate REST principles as well. Cookies are now so pervasive that it is rather
difficult to use most commerce-oriented web sites with cookies disabled; does
this contradiction say more about the web-as-it-really-is or the REST
I really don't have an axe to grind here, I'm just trying to understand what
practical course of action the REST principles suggest vis a vis the challenges
of the Web Services architecture.