[
Lists Home |
Date Index |
Thread Index
]
2/20/2002 12:57:39 AM, "Joshua Allen" <joshuaa@microsoft.com> wrote:
>
>This has nothing to do with RPC vs. REST. I remember when Rob McCool's
>HTTPD first started to proliferate and people started hooking up CGI to
>/bin/sh. It was really cool; you could do http://someserver/sh?rm+-rf+.
Nice counter-example! I was thinking about how easy it would be to do this with
a SOAP toolkit, but it's not a challenge with HTTP (as we use it anyway) either.
I think I'm convinced that idiocy with respect
to security is neutral with respect to RPC vs REST.
>
>Again, I don't understand this. RPC does not pass code to the server.
>The user does not "execute code directly". The user passes some
>parameters, and the server executes whichever code it has been
>configured to execute in response. Same as happens with REST.
Al Snell made the same point, and I definitely shouldn't have said
"directly." The point about Melissa-esqe viruses being triggered by mail clients
and naive users rather than RPC or SMTP is also well-taken.
I guess it comes down to my conception of the SOAP
architectural style vs the REST architectural style. SOAP
encourages a software engineering approach of building software
components that can be invoked remotely. I can easily imagine how
a componetization that was not rigorously audited for security
vulnerabilities could leave too-powerful operations exposed
to the internet. REST, on the other hand, encourages a
"document processing" approach where the remote user submits
data to a URI, and that triggers some executable version of a
business process. It just seems a lot less likely to leave a hole in
one's business process that says "exececute an arbitrary piece of
code" than to leave a hole in one's software architecture that says
"execute an arbitrary piece of code."
It would appear that security is not a differentiator
between RPC and REST at the *technical* level. I still think that
the basic design pattern of considering Web Services as flows of
business documents makes it easier for a non-expert to design a
secure system than when one considers web services as
as the remote invocation of software objects. The "flows of
documents" design could be implemented in either SOAP-RPC or REST,
no dispute, but it just seems more RESTful than SOAPy to me.
I keep coming back to the same basic opinion: SOAP-RPC and the
tools that support it are great for building distributed applications
within an enterprise, behind a firewall, where people basically trust
each other (and violations can be traced and punished), and where
reliability and latency are either not a problem (or can be handled
in a straightforward manner, such as with the extra step in VS.NET
that Francis Norton mentioned). In these situations, you can indeed
"hide the network behind the tools." But when you can't hide the
network because of lack of bandwidth, latency, trust, reliable
connectivity and so on, or you don't want to hide the network for
some other reason, REST looks like an awfully good design pattern.
|
