[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What Does SOAP/WS Do that A REST System Can't?
Rich Salz wrote: >>>You've doubled the reliability, security, and server-state load, >>>but it is RESTian. For many applications that won't be enough. >> >>Where do you get the factor of two from? > > Twice the number of HTTP messages, nothing more simple then that. Fair enough, although not in all cases. For the example we were discussing (searching) an application is likely to immediately GET the url to view the results. In *other* applications of the same message pattern, there's requirement for the client-side application to immediately follow the Location header and perform a GET: * If a new resource is being created, then a client may be sufficiently happy that its received a redirect(*) rather than an HTTP status code. A GET on the new URI may be redundant as it'll echo back the data I just sent the server. So one message and a cheap response * In other scenarios a client may choose to perform the GET in a few minutes time, or next week. So the pattern supports asynchronous usage which is handy. (The server may not actually carry out the original request until the GET is issued, so this pattern can be properly asynchronous) * The client may actually issue a conditional GET which results in smaller server responses, so again it can be efficent. So I accept that yes there are 2 messages, but there's a lot of variables to consider and options available. I'm not sure I see those same options with a "POST to controller; return response" approach. > As for server-state, the server now has to maintain state behind > the GET'able URL, make sure that it's the same client coming back > or otherwise deal with authorization decisions, etc. Whether its inconvenient for the server to maintain state depends on whether the results of the POST are the creation of domain objects -- these will have their own lifetime and are likely to be maintained anyway. So there's no real difference between the approaches there. For the search example, keeping track of what searches a user has performed may or may not be a significant factor for the application. But recall that we were talking about a healthcare application. If the result is a single hit, i.e. I've found the relevant patient, then the returned URL is just that of the patient (i.e. the domain objects) so no additional state management required. Re: authorization decisions. It's no harder to protect, say /* with an authentication filter than /controller, so I don't see any difficulties there. So the answer, as usual, is "it depends". But I thought it worth responding as I wanted to challenge the assertion that REST message patterns are automatically less efficient, harder to protect, etc. As ever application design trade-offs come into play, but as I've noted above I see more options with a REST style approach. (*) in this thread I've kept writing 302, when in some cases I ought to have suggested use of 303 See Other. Apologies. Cheers, L.
|
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
|