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. > 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. 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. > 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) - 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. 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). It doesn't solve everything, but it solves some major issues in a reasonably simple way. > 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. > 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 :-) Cheers Stu __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/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/
