Steve Jones wrote: > On 19/12/06, Mark Baker <[EMAIL PROTECTED] <mailto:distobj%40acm.org>> wrote: > > But to answer your question, we make it painless by using an > > architectural style, standards, and software best practices which can > > accomodate change. I can't claim that any change to an app using a > > Web based stack won't result in a broken application, but they're far > > more robust than those built atop a Web services stack. > > Hang on Mark, if someone turns off the server then you don't get a > 404, you get nothing at all. With a SOAP client you get a SOAP fault > from the client due to non-connection, with REST you get _nothing_ > which doesn't fit into the 404 processing.
In particular, in line with my previous posting, how in the world does the web client now know what else to try to get "service"? The hypermedia that contained the "broken link", would have to provide the alternate navigation choice. There are examples of this visible on, for example, sourceforge download pages. But, the user has to "pick" the next best choice based on "their knowledge" which is very disconnected from the services' knowledge of their own state. But, the client can't talk to a service that it can't connect to. This is a particularly troublesome part of web/REST/http design. Gregg Wonderly
