[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?
Mike Champion wrote: > >... > > I'm beginning to see the point now. Perhaps I'm too dense to get the subtleties > here: does this point of view tend to invalidate the SOAP/WSDL paradigm or just > suggest that the RPC message exchange pattern should probably not be implemented > over HTTP? Even many people who have never heard of REST tend to agree that the RPC paradigm is bankrupt for inter-organization web services. That's why SOAP has been moving more and more from RPC towards "envelope" with each version. The problem is that many people use the word "SOAP" to mean very different usage models. These different usage models will not be compatible with each other. In fact, if you look at the first part of the SOAP spec without the second, you can see how it would add some value to HTTP as a way of doing structured headers with named intermediaries. RPC swings in and out of favour because it seems "so easy" but then when you try to scale it up to big problems you find extensibility, latency and security issues. > ... Of course, this MEP accounts for about 99% of the actual use of SOAP > in practice, AFAIK ...and 100% of XML-RPC, so this isn't a "big guys vs little > guys" or "simple vs complex" cleavage. RPC is simpler because programmers are used to doing function calls in their programs. People are getting great value out of RPC -- but not for things like supply chain management etc. Really, except for the bias, most SOAP-RPC stuff is stuff that could as easily be done with CORBA. And in Python, at least, it would be easier in CORBA than SOAP-RPC because the implementations are so mature. I've heard that Java's CORBA binding is not too pretty so that may be part of its lack of success in that world. But we (the community, not any standards body) rejected CORBA for web services because it isn't the right model for inter-organizational messaging. > Sean McGrath has a nice article on this subject > http://www.itworld.com/nl/xml_prac/01312002/ "Having read the dissertation, I'm > having trouble reconciling this "Web as API" view with the REST architecture. Is > it feasible to implement the Web services vision on top of the Web without > violating the principles in REST, which made the Web work in the first place?" Wow. I hadn't read that article before. Looks great! Sean and I are sort of kindred spirits. If he joins the REST team it will be our third or fourth shared heresy: SGML instead of Word, Python instead of Java and now REST instead of the Standard Web Protocol Stack. > So, we apparently agree that REST raises issues that Web Services need to > address. So how do people think the issues will be resolved? In what concrete, > pragmatic way will the contradiction between REST and RPC over HTTP potentially > cause the Web Services bubble to burst? Maybe it won't. Maybe a lot of services will be built with RPC and over a relatively short period they will become "legacy services" as people figure out better ways of doing things. But as I said above, SOAP and RPC are no longer synonymous. SOAP is a chameleon. You can project your hopes and dreams onto it and it is flexible enough, with enough optional features, to always deliver. Unless your hope is interoperability. ;) > To put it differently, Sean says 'I'm having trouble reconciling this "Web as > API" view with the REST architecture.' OK, I do too, but he notes that cookies > violate REST principles as well. Cookies are now so pervasive that it is rather > difficult to use most commerce-oriented web sites with cookies disabled; does > this contradiction say more about the web-as-it-really-is or the REST > architectural principles? But Microsoft is trying to replace (most of) cookies with .NET My Services. Their solution is very RESTy. Personal information becomes a resource served off of the Web, instead of being implicitly passed from client to server. Unfortunately their REST model layers about four or five standards on top of HTTP so that it becomes difficult to integrate with it...but there are many ways it is RESTy. HTTP looks roughly like: DELETE URL <data>...</data> .NET My Services looks roughly like: <delete xpath="..."> <data>...</data> </delete> > I really don't have an axe to grind here, I'm just trying to understand what > practical course of action the REST principles suggest vis a vis the challenges > of the Web Services architecture. #1. I think we need to all think about protocols more systematically. We need an xml-dev for web services where people don't just mindlessly accept the protocols they are handed down from On High but discuss them and compare them. #2. We have to think clearly about why the strategies of the past do or do not apply. RPC is the most obvious example. HTTP also comes in for criticism on the basis that it is designed for human->computer communications. I don't think that's true but it is worth discussion. These are not very active actions but I think that understanding must precede action (and especially standardization!). Paul Prescod
|
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
|