I'm really going to have to work for a living in a second.... On 03/07/06, Stuart Charlton <[EMAIL PROTECTED]> wrote: > > > > > > > > see Inline > > > --- Steve Jones <[EMAIL PROTECTED]> wrote: > > > Sorry for this, but I call snake oil. REST does not > > improve loose > > coupling, I still need to know the document formats > > and the URIs. > > > Loose coupling != "no coupling". > > It's a lot looser than prior approaches, where you > also had to share the programming language (Java RMI), > or the operating system (DCOM), or the broker > implementation (CORBA). These are not minor issues, > they were show stoppers, for many.
All of which could be solved with advanced approaches such as CSV and file servers. I'm not saying its rubbish, just that it isn't magic. > > > > Spot on from one perspective, architecturally (and I > > mean architecture > > here, not implementation) the whole point is that A > > wants to interact > > with B. REST doesn't change that. > > > I don't believe that's the whole point. The goal is > that A wants to interact with anything that shares > data semantics with it, without requiring > modifications to consumer or producer. And the entire semantic web effort sort of indicates that this is a bit of a challenge. > > Such network effects, even if shallow, have tremendous > economic benefits. An application, such as Google > search, for example, doesn't need to know what data > types are on the web sites, it just needs to > understand HTTP and HTML, PDF, TXT, maybe PPT, etc. > and URIs to do ranking. Or to be clear it needs to understand the document types of HTML, PDF, TXT, DOC, PPT etc to understand what is content and what is not. > > > > You also seem > > to be suggesting that REST is magic pixie dust that > > requires no effort. > > > I'm merely suggesting that HTTP (as an example REST) > encodes capabilities that many have already agreed > upon, so there is negligible effort, for example, to > have to create another way of > - referencing an endpoint or resource (URIs) > - accessing a resource without side effects (HTTP GET) Not actually guarenteed by HTTP GET but by the assumption on it. As an example, if I have a web counter that is accessed via HTTP GET there is nothing in the specification that stops that counter being updated via the GET request. > > - updating a resource (HTTP POST). > > All of this stuff is implicit, none of it has to be > thought through by the consumer of a service. But none of these actually deliver functional and benefit to the consumer, that is ontop of these elements. > > The two big ideas here are the URI and the "universal > side-effect-free GET", I think. While these are > implementation examples, they have tremendous > architectural implications on what's possible. Major > classes of interaction become autonomous - I don't > need to know who's going to consume me nor do I need > to really know a specific producer in advance. > Coupling is pushed to the shared data types and the > generic operations (GET). Even ignoring the GET assumption, the linking around the data types is fairly significant. There is also the challenge (solvable via URIs) of what to "GET", which needs to be clearly documented and communicated to consumers. This is one of the bits that I'm confused about, I don't see how REST solves this publication and management challenge. > > It doesn't solve everything, but it solves some major > issues in a reasonably simple way. I might be too abstract for this stuff, but over using WDSL and an IDE, what is simpler for the developer? > > > > Computer Science is something that people should > > understand (and its > > sad how few people do), but the difficult bit is the > > people, politics, > > economics and semantics. > > > Completely agree, though I think they're both equally > important and difficult, though perhaps the more > high-profile blunders have been on the human side. Which is why I say the other stuff is the challenge. Technology is relatively easy, people is NP complete. > > > > We love re-inventing the wheel in IT and pretending > > its actually new. > > > As well In business, in economics, etc.. how many > times does "listen to your customers" come back into > fashion with a new fad ? Or how about the eternal > centralization vs. decentralization debates? Or, in > economics, the various "what causes growth" arguments. > > Our collective amnesia is wonderfully stimulating and > infuriating :-) Totally agree... but how many times in business does a vastly discredited idea come back to the fore? In IT an idea that has failed just needs to wait 6 months before some way says its the big solution. Definately business evolves and has circles, but over in IT we dig up the corpses of the dead projects, whack in 70,000 volts of new investment and proclaim it the future. IT is more broken than business IMO, and REST v SOAP/WSDL is an example of the problem. Its an interesting debate, but does it move the state of the art on? I'm really not seeing it. > > > Cheers > Stu > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> 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/
