Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SOAP-RPC and REST and security
 After all the hundreds of posts (this time around) on this subject, I still am not convinced that most of the things that have been claimed to differentiate RPC from REST actually do that. I suspect that the differentiators are very few, and very simple in concept. When I first learned about xml-rpc a few years ago, my first reaction was that it offered a way to send form-like data that was more structured than name:value pairs. It seemed to be a natural evolution of form data, like going from CSV to XML. The fact that you could arrange to write code (at least in Python) that looked exactly like a method call on an object was sort of cool, and made things seem more familiar, but didn't seen essential. Then SOAP got complicated and blurred matters. Consider this: when you send an HTTP request, GET or POST, with query parameters, you are invoking a lot of network operations that you don't know about, and asking the server on the other end to perform some operations, selected by the parameters, that you don't know about, finally perhaps getting some data back. We have a metaphor that we are asking for a "page","document", or "representation of a resource", but really we are just getting data. It may be made up on the fly, who knows? When you make an RPC call, you invoke a lot of network activity that you don't know about, and you ask the remote server to use a series of parameters to perform some operations that you don't know about, finally perhaps getting some data back in some structured format. What's different? Not that you sent parameters to a server over a network. Not, probably, the complexity of the parameters. Even the supposed difference between a "representation" of a resource vs. function invocation seems to me to be a red herring. It reminds me mostly that you can view almost any system from a procedural- or a data-centric view, and sometimes one or the other will be more convenient. Which one is most productive is likely to be partly development style and partly what the invariants are in the system. The statements that you should not expose the raw resource to the network's tender mercies are only restating that good practice used for years in the relational database world, where you know you should expose views rather than tables for just these reasons. What, then, is left as a differentiator between REST operations and RPC operations? It seems to me only and exactly the few key things that differentiate REST itself from other network architectures. Universal addressing, a small set of universally understood operations (e.g., GET,POST,PUT, etc.), a small and relatively simple suite of network control functions, right? Viewed in this way, you can almost run a checklist, and the results seem to align well with what Paul Prescod has been saying. Taking SOAP as an example, does it use universal addressing? Well, yes and no. It uses a URL to get to a server, but then can have other routing information embedded in it. Does it use a small set of universally understood operations? Well, once you get past the original POST, no it doesn't. OK, but so what? It seems to me that a REST system, being simple and highly public, is open and easy for people to attempt to hack or spoof, since there are only a few well understood commands. Several people have provided good examples in the last few days on the list. The other side of the coin is that protection is easier to understand and incorporate, since the number of possibilities to deal with are smaller than for some other network architectures. This, too, has been remarked upon. Just the reverse, then, would seem to apply to an (non-REST) RPC-based system. Being less open (or not open at all if we follow Len's advice for highly important material), and both more complex and less commonly understood in its commands, it should be less subject to successful hacking and spoofing, but harder to protect against when it does occur. What's the bottom line here, which way should be "better", more secure? Not obvious, not to me at any rate. But then I don't have practical experience building large systems like this. Simplicity, though, is likely to be better for building large numbers of large, reliable systems apart from security, and this would favor REST, wouldn't it? Cheers, Tom P 
|
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
|
|||||||||
