Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: HTTPEctomy considered bad (was RE: RE: MS thinks
 This is a somewhat long and rambling post. Sorry about this, but I've thinking about this a fair bit (while still trying to absorb REST). > From: Sean McGrath [mailto:sean.mcgrath@p...] <snip/> > 2) SOAP will be transport independent. Doesn't that sound > really appealing? > This mantra is already gathering pace. The fact that most > developers trust deep > magic to make RPC work over both HTTP and SMTP without > thinking about the fundamentally different transport model of > each is testimony > to how powerful that mantra is. Although I am essentially won over to the REST perspective, now, I still think most of the REST advocates who keep arguing against SOAP still largely miss the appeal that SOAP offers to the average developer. I'm not disagreeing with your points. But I'd like to add another perspective for those who really want to win mindshare for REST among those attracted to SOAP. First, in terms of protocol independence, there is some appeal to being able to accept a message via HTTP, queue it somewhere else (including simply in the file system), and process it later without any loss of fidelity of the information it contained -- and without having to transform all of the pertinent information into a different format to accomplish this. That's part of the appeal of being agnostic with protocol. I'm not saying this is the right way of doing things. I'm saying that SOAP developers care about the *information* -- not the document format or the protocol -- and they want to be able to *easily* move that information around without loss of fidelity. Fixating on proper use of HTTP doesn't seem likely to offer a counter-solution. Defining a framework for smarter protocol bindings that can support that ease of moving information around while respecting protocols that get leveraged would seem like the right avenue to explore. HTTP is not the center of the universe to the SOAP developer. Second, I honestly don't buy the notion that the average SOAP developer really cares about RPC. I think the average developer cares more about the APIs than the protocol. They want to work at a higher level with data structures and APIs that are a *natural fit* for their programming language of choice. I have yet to meet a business developer who likes working with the DOM (or any equivalent model). This is the real appeal of SOAP RPC. I see no reason why there could not be frameworks offering data-binding and modelling resources as first-class objects with stongly typed methods for doing things that abides by REST under the covers while providing the same sort of ease-of-use that SOAP toolkits offer. Indeed, elevating the addressable resources to first class objects in the model seems to offer a richer model with which to solve problems. This seems like it is an opportunity to win over SOAP developers. You'll have to wean them from generating the XML formats from APIs, but I don't think this is a big leap. I've seen tools marketed that let you generate an ER model from APIs, but I have yet to see a real world project that uses them. Every project for a database application in which I've been involved always made the data model central, and designed the APIs out from that. It shouldn't be a big leap to convince web services developers to do the same. > 3) Developers will be urged to write to the SOAP "API"s > exclusively in order > to insulate their systems from transport dependencies. This will be > marketed as something all conscientious developers should do. It's what most developers *want* to do. They want easy to use APIs that are more aligned with the business problem they are trying to solve than protocol details. They don't want to have to muck with low-level protocol details every time they need to solve a business problem. This is the EJB model. How many EJB developers are there today, compared to those who deal directly with CORBA or RMI? Is the success of EJBs just because of app server vendors pushing it, or is there genuine appeal to the API-centric approach? I think the latter is very much the case. The EJB model avoids vendor lockin by standardizing the APIs rather than the protocol (except for the fact that you are locked in to Java). Obviously, web services standards need to focus on the protocol. I'm not arguing otherwise. But we should lose sight of the appeal to developers. To most developers, it the APIs that abstract away the details of XML formats and networking protocols that are attractive. <snip/> > By the time they are doing that, I fear the world will have > forgotten that REST > presented an alternative, and I would argue significantly > more powerful, > data-flow based approach to building systems. Unless some folks get out in front of this and offer toolkits for developers that let them work with APIs and data structures that are a natural fit for the programming language of their choice, but which also promote REST principles. If the tool makes it relatively easy to take any first-class object in the business model, and model it as a URI-addressable resource -- rather than making those objects opaque to the protocol -- there's a shot at winning some mindshare. Maybe I can steer my little side project [1] in that direction at some point. But I have my hands full with some other goals for that, right now (as well as my day job). I have been doing some thinking about this, though, so I'll offer some of my current thoughts and see what people think. REST advocates seem to look at things in a rather document-centric fashion. There's nothing wrong with this model. But then, there is nothing wrong with the model of those who want to view a document as just a bag of elements for which the notion of any top-level document type -- or media type -- is not particularly meaningful. If REST advocates want to win over the web services community, they need to find the way to accomodate this model in REST rather than insisting this model is wrong. I think if REST is to appeal to the SOAP-RPC community, it needs to accomodate a more granular and component-oriented notion of resources. For instance, SOAP has the notion of pass-by-value or pass-by-reference. This is a common notion in the programming world. One of the strengths of the SOAP envelope is a reserved place for elements that describe shared context (e.g. authentication info). Paul Prescod wrote in one of his articles (I forget which one) that shared context should be modelled as resources. I like that idea. But I still think we need a notion of pass-by-value. If one little message requires the endpoint to start doing a bunch of 'GETs' across the internet for all shared context, things quickly get out of hand. The OO world is quite used to the notion of an object being an aggregate of other objects. Subordinate objects may or may not be independently addressable. We need a framework for modelling such notions in a REST-ful way. There must be support for resources that are aggregates and that offer representations for which the notion of a top-level type (other than XML with namespaces) is not meaningful. The very fact that an RFC had to be issued to try to let media types make peace with the XML world with an "+xml" suffix (and the debate that swirled around that RFC) is clear testament to the fact that there are broadly employed uses and processing models for XML for which the notion of media type is useless (other than to know it is XML). Any notion of web services that tries to shut down those uses and processing models is doomed to fail. There must be a way of conveying aggregated representations of resource states. The latter could be made more REST-ful with hyperlinking. Any business application relies upon some mechanisms for making objects addressable. These could all typically be mapped to and from URIs. So maybe we just need a modular convention for XML message formats that let you embed some inline element annotated with an href (perhaps making the element an Xlink simple link) that specifies the "home" URI for the resource represented by that element. It's kind of a way of saying "here's the URI for some shared context, but I've saved you the trouble of getting it by including an inline state representation". If I have to tell a client to do 10 separate GETs to do something that can be done with one method call in a typical non-REST-ful distributed app, there's a problem. I don't know that this is anti-REST (that's not clear to me). I go back to an exchange that Paul Prescod and I had awhile ago [2]. Paul's solution is an interesting one, but I have a problem with the notion that I can't do this with a single XML document. It seems like this could be made to work with REST if the resource representations are not opaque. If we can recognize links in them (e.g. via XLink), then we should be able to define conventions by which we can also recognize inline state representations of other resources, and that could afford some richer processing models. Does this make sense? The recipient of such a message could recognize the inline state representations for what they are, and know what resources they represent and be able to address them independently since it also has their URIs. A further convention for distinguishing between those that represent shared context, and those that are directly pertinent to the resource being addressed, also seems useful. The SOAP envelope and conventions partially address this (with its notion of Header vs. Body). It falls short in failing to model these inline objects as addressable resources in their own right. What's a better way of doing this? Well, that's some of my thinking this week on this stuff. Any merit to this? [1] http://swan.sourceforge.net/ [2] http://lists.xml.org/archives/xml-dev/200202/msg00444.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
|
|||||||||
