On Apr 5, 2006, at 5:22 AM, Sanjiva Weerawarana wrote:
> 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!
>
No problem, since we're having a technical discussion here - I'm
extremely hard to offend, anyway :-)
I'm not describing this because I doubt you're familiar with it, it's
just that you asked for an explanation about "what's different".
Interesting that you perceive *this* as BS. I find HTTP a pretty
concrete spec, with rather clear descriptions of the different
methods' characteristics, for example. Far more concrete than many
of the documents and architectural descriptions from the SOA space I
deal with most of the time. Including my own.
> 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?
If they build useful applications: no, they're definitely not wrong.
If they called them RESTful just because they happened to use HTTP -
yes, I'd say they'd be wrong. (Which is not the end of the world, but
that's not the point).
>
>> 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 disagree there's human required "on the other side" to make sense
out of this. There's lots of useful things I can do with a resource
identified by a URI with minimal knowledge about the concrete
representation; if I know it's XML, there's even more. For example, I
can build a service that transforms XML using XSLT, or runs XQuery
against it, or extracts data via XPath; I can pass URIs to it and
because of the uniform interface, it'll be able to GET the
representations and use them in a meaningful way. Nothing prevents me
from using XML Schema or other schema languages in a REST scenario,
either. I think the importance of a description language for REST-
based services is overestimated.
>
>> 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.
So we agree.
> 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.
>
I haven't taken the time to really look into WSDL 2's details, so
I'll take back the criticism for now since I can't back it up with
qualified knowledge. It's great to see that WSDL 2 supports
describing Web resources. I have strong doubts, though, whether it is
ever going to be used for this purpose in a significant number of
scenarios, though -- it seems far too complex for such as task alone
(which is understandable, since that is not its main purpose).
I assume you are aware of the discussion going on at public-web-http-
[EMAIL PROTECTED]; even there, activity is very low, probably another sign
that the need for a description language is not as significant for
RESTful services.
>> 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 ..
>
I don't think I'll be able to convince you, there's possibly others
who might have a better chance. And I don't really *want* to convince
you that "all is broken with Web services and all is well with REST".
The original discussion was about whether the differences between
REST and the-other-style-the-name-of-which-we-can't-agree-on can be
hidden behind a common programming model. And it seems to me we agree
that they can't be, unless we redefine REST to mean "plain XML over
HTTP". Right?
Best regards,
Stefan
> Sanjiva.
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
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/
