[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
>
>...
>
> 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?
Even many people who have never heard of REST tend to agree that the RPC
paradigm is bankrupt for inter-organization web services. That's why
SOAP has been moving more and more from RPC towards "envelope" with each
version. The problem is that many people use the word "SOAP" to mean
very different usage models. These different usage models will not be
compatible with each other.
In fact, if you look at the first part of the SOAP spec without
the second, you can see how it would add some value to HTTP as a way of
doing structured headers with named intermediaries.
RPC swings in and out of favour because it seems "so easy" but then when
you try to scale it up to big problems you find extensibility, latency
and security issues.
> ... 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.
RPC is simpler because programmers are used to doing function calls in
their programs. People are getting great value out of RPC -- but not for
things like supply chain management etc. Really, except for the bias,
most SOAP-RPC stuff is stuff that could as easily be done with CORBA.
And in Python, at least, it would be easier in CORBA than SOAP-RPC
because the implementations are so mature. I've heard that Java's CORBA
binding is not too pretty so that may be part of its lack of success in
that world. But we (the community, not any standards body) rejected
CORBA for web services because it isn't the right model for
inter-organizational messaging.
> 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?"
Wow. I hadn't read that article before. Looks great! Sean and I are sort
of kindred spirits. If he joins the REST team it will be our third or
fourth shared heresy: SGML instead of Word, Python instead of Java and
now REST instead of the Standard Web Protocol Stack.
> 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?
Maybe it won't. Maybe a lot of services will be built with RPC and over
a relatively short period they will become "legacy services" as people
figure out better ways of doing things. But as I said above, SOAP and
RPC are no longer synonymous. SOAP is a chameleon. You can project your
hopes and dreams onto it and it is flexible enough, with enough optional
features, to always deliver. Unless your hope is interoperability. ;)
> 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
> architectural principles?
But Microsoft is trying to replace (most of) cookies with .NET My
Services. Their solution is very RESTy. Personal information becomes a
resource served off of the Web, instead of being implicitly passed from
client to server. Unfortunately their REST model layers about four or
five standards on top of HTTP so that it becomes difficult to integrate
with it...but there are many ways it is RESTy. HTTP looks roughly like:
DELETE URL
<data>...</data>
.NET My Services looks roughly like:
<delete xpath="...">
<data>...</data>
</delete>
> 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.
#1. I think we need to all think about protocols more systematically. We
need an xml-dev for web services where people don't just mindlessly
accept the protocols they are handed down from On High but discuss them
and compare them.
#2. We have to think clearly about why the strategies of the past do or
do not apply. RPC is the most obvious example. HTTP also comes in for
criticism on the basis that it is designed for human->computer
communications. I don't think that's true but it is worth discussion.
These are not very active actions but I think that understanding must
precede action (and especially standardization!).
Paul Prescod
|
