Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Web Services and REST: what is to be done?
 > From: Mike Champion [mailto:mc@x...] <snip/> > So, we apparently agree that REST raises issues that Web > Services need to > address. So how do people think the issues will be resolved? Well, for one thing, I think there is an awful lot of dogma and religion around REST. There are certainly sound principles in REST. But there are also very real business problems that people are going to solve with web services. If REST cannot support these, then the REST folks will lose regardless of what theoreticians and spec committees have to say. With that said, certainly web services should be sensitive to issues related to web architecture. But when I hear a suggestion that every XML format that will ever be submitted through an HTTP server needs to have a unique media type assigned, I don't think that is an area where the web services folks need to bend to REST. This is an area where REST needs to evolve. REST was designed as an architecture for hypermedia systems. It has not proven itself in the world of complex business process workflows, which is a key part of what web services address. So treating it all as unquestionable truth is a mistake. We are entering a new domain, and REST has to prove it is up to the task. When I read REST papers, many of the principles sound quite familiar to me. They are things I was doing in distributed OO systems long before anyone had written about REST (or at least long before any of the REST papers I've seen publicly cited). Things like not maintaining session-state between client and server, adhering to meaningful identifiers for objects (or "resources" in the REST view) that can be leveraged by caching mechanisms, using generic interfaces and limited sets of verbs. I've heard too many REST folks claim they have insights that the OO folks don't understand. I haven't heard them, yet. Of course, when I wrote those distributed OO systems, we also used design patterns like Command[1], Composite[2], and Chain of Responsibility[3] -- things that some REST folks insist are wrong. We used them because they were useful and needed. I think web services have more to learn from proven OO patterns than from REST, here. Indeed, many REST folks seem fond of mischaracterizing OO. As one minor example, I'm looking right now at the paper by Roy T. Fielding and Richard N. Taylor [4] and find this quote: Unlike the distributed object style..., where all data is encapsulated within and hidden by the processing components, the nature and state of an architecture's data elements is a key aspect of REST. Sun's J2EE blueprints[5] espouses a pattern they call "value objects" -- lightweight objects representing externalized state that can be exchanged among components in the system. This is not a new pattern. I was using it in distributed OO systems long before there was a J2EE or papers on REST. Indeed, at the time I was using Forte 4GL, and Forte had a technote for developers that explicitly advocated this pattern -- and for the same reasons REST does. This is not new, and it is not counter to OO. I would like anyone advocating REST to tell me the correct way to handle the very simple case I have already cited [6]. If there is a better way to do this, I'm happy to learn. But the only thing I've heard suggested so far is to break this hierarchical composite into a bunch of smaller messages that must be sent independently. If that's what REST says, then REST is wrong and the web service community must recognize that the REST folks don't have all of the answers we need. To break this composite into smaller messages would be to expose dependencies (such as dependencies upon order of execution) to the client that should not be exposed. I get challenged to prove that REST cannot address all conceivable business functionality, yet this example is a rather trivial one that no one has responded to, yet. If I cannot do even something as simple as this with REST, how am I supposed to build enterprise systems with REST? I think it's for the REST folks to prove REST is up to the task, not for others to prove REST can't do it. Apart from that, I'd be happy to see BEEP or another more fitting protocol gain prominence enough for it to be a viable option for me. I'm not wedded to HTTP. But I need real solutions, not religion. I'm not hearing real solutions. [1] http://www.fh-konstanz.de/studium/ze/cim/projekte/osefa/patterns/command/int ent.htm (not a helful link, but all I can find) [2] http://www.fh-konstanz.de/studium/ze/cim/projekte/osefa/patterns/compos/inte nt.htm [3] http://www.fh-konstanz.de/studium/ze/cim/projekte/osefa/patterns/chain/inten t.htm [4] http://www.cs.virginia.edu/~cs650/assignments/papers/p407-fielding.pdf [5] http://java.sun.com/blueprints/enterprise/index.html [6] http://lists.xml.org/archives/xml-dev/200202/msg00376.html 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
