I sent this earlier today but it doesn't seem to have made it. Apologies
if this becomes a dup. (Not sure whether Gervas is moderating each mail
one by one.)
Sanjiva.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
--- Begin Message ---
Hi Stefan,
> See below - the key distinction is that a RESTful HTTP service will
> expose a number of resources, each of them supporting the same
> interface. When you design an application this way, you'll usually
> start by thinking about the resources you want to expose, how the
> different verbs (GET, PUT, POST, DELETE) affect them and what kinds
> of representations they have.
Yes I'm familiar with all this .. having participated in this debate
since about 2000 .. and repeatedly with Mark Baker and others :). With
all due respect, this is high level architecture BS. I'm sorry if that
offends you; that's not the intent: I'm trying to communicate my honest
view of the matter!
When it comes down to it, when developers write applications they decide
what APIs / protocols to support based on who the expected clients
are .. they don't spend their life worrying about the fixed interface
vs. resources-oriented design etc.. I'll bet you that a large majority
(90+%) of PHP programmers have never *heard* of REST or Roy Fielding or
Chapter 5 and don't need to care. Are they all wrong?
> All of this enables interoperability with the
> widest possible variety of clients - anything supporting HTTP,
> including a browser, curl and wget - at the cost of a generic interface.
This is all nice when you have an intelligent machine like a human on
the other side .. when you have some really dumb software then that
better understand the data involved. The fact that you can put the data
in a fixed set of "operations" is but a detail in the interaction IMO:
the hard part is knowing what data to send to understand what data is
coming out. IMO that's the failing of REST: it assumes that the problem
is down to designing resources and the safety of operations and doesn't
have anything to say about how to design the data that's going back and
forth. Even REST needs a way to describe the format of the data going in
and coming out, if you expect a non-intelligent thing like a computer to
be able to do something with it on the other side. You may not like
WSDL, but you need some way to at least say "data conforming to this
schema goes in, and data conforming to this data comes out".
> I'm not even necessarily implying one way is better than the other,
> just that they are different. If Axis2 supports the same programming
> model regardless of whether there's a SOAP envelope or not, that's
> cool. It just doesn't make it any more RESTful.
That's fair enough .. so maybe the mistake I made is in using the word
REST- what we're doing in Axis2 is providing a programming model where a
service author or client can deal with services which publish a SOAP API
or an HTTP GET/POST API uniformly. Whether that approach makes
RESTafarians restful or restless is not really important ;-).
> > So I'd like to understand what's broken about it.
>
> I hate to say it, but I believe that it's WSDL 2 that's broken ;-)
Have you really looked at it in detail? I assume you know Dan
Connolly .. I'll note that even Dan, who's one of the strongest
RESTafarians I know, was quite happy and pleased with the WSDL 2.0
models services. Of course, YMMV.
> Exactly. Not only do I believe the two styles - let's call one REST,
> the other one WSDL - are different, I also think there is no sane way
Just a small clarification: WSDL does not define a style: its simply a
way to describe message exchanges patterns (called operations) where
each message has associated with it some data and policies. That's it.
Using it to describe REST style patterns is possible. Using it to
describe RPC style patterns is possible. Using it to describe messaging
patterns is possible. Using it to describe other weird message exchange
patterns is possible. Summary: WSDL does not define or imply an
architectural style.
> to consolidate them. Which is said, because REST is basically what
> defines the Web. Everything would have been a lot easier had "Web
> services" been called something else from the beginning.
:-).
> On the Web, resources have a URI. Do WSDL 2 operations have one? If
> they don't, "resource" is probably not the best term to choose.
Every operation can have its own URI if that's what you want.
> Absolutely, yes - no technology should be turned into religion. To
> judge whether and how a technology or architecture is applicable to a
> given problem, one should be sure to understand it. No offence
> intended at all, but I know from personal experience that my opinion
> about REST changed a lot the more I got to know about it. I started
> out as a firm believer in the WS-* vision and ended up a closet
> RESTafarian (of the Hi-REST variety, even).
Wow, a true convert :-). I have listened to (and participated in)
arguments on this topic for 5+ years but have not yet been convinced. Of
course you could say I've been biased from day 1 .. considering my WSDL
legacy and all. However, I was a research guy (and still am to some
extent) and am ready to learn anytime.
So far, I haven't been convinced that all is broken with Web services
and all is well with REST. I'm still willing to be converted if you have
a new argument ..
Sanjiva.
--- End Message ---
