On 19/12/06, Mark Baker <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> On 12/18/06, Alexander Johannesen <[EMAIL PROTECTED]> wrote:
>  > No one can solve the problem of people turning their services
>  > completely off, but how do we make sure that switching from one to
>  > another is as painless as possible?
>
>  This reminds me of the Web services proponents who claimed "HTTP was
>  unreliable" because it **reliably** told them that somebody turned a
>  service off (with a 404 response code, of course).

Sort of like getting a SOAP fault (which you also get if the server
isn't available).

>
>  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.

How is that more robust?


>
>  Mark.
>                    

Reply via email to