|
SOAP and XML-RPC are XML protocols used for application-to-application
communication over the Web. REST (Representational State Transfer) is an
architectural style for distributed hypermedia systems.
SOAP is an extensible XML protocol that
forms the foundation for what most people view as Web services. (XML-RPC and
other technologies may also be used to implement Web services, but I think
that at the moment, SOAP has the most mind-share.) SOAP supports a number of
message exchange patterns, including one-way messaging, RPC-style
request/response messaging, SOAP response messages, asynchronous messaging,
and more. SOAP messages can be transferred using any transfer protocol (such
as HTTP, SMTP, JMS, etc.). It defines a data model and type system based on
the XML Schema type system. The message envelope is called <envelope>. It
contains two child elements: an optional <header> and a mandatory <body>. The format of the header and body are not defined.
XML-RPC spun off from the early SOAP effort when Microsoft politics delayed the release of the original specification. XML-RPC is a very simple XML protocol. It only supports RPC-style
invocations. It only runs over HTTP. It doesn't use a data typing system. It
doesn't support headers. The message envelope is called <methodCall>, which
contains a <methodName> element, which contains a <params> element, which
contains a set of <param> elements.
REST defines the modern Web architecture (which is a much larger topic than
application-to-application communication over the Web!). It's an immensely
scalable architecture that has changed the way we do computing. REST defines
an application protocol called HTTP. HTTP has four application methods: GET,
PUT, POST, and DELETE. GET is used to retrieve a Web resource. PUT is used
to modify a Web resource. POST is used to create a Web resource. And DELETE
is used to remove a Web resource. Each Web resource is uniquely identified
by its URI, and every Web resource can be linked to, bookmarked, and/or
cached.
There has been some controversy regarding SOAP and REST, and I suspect that
this is the point of your question. Some folks have gone so far as to say
that SOAP isn't "Web-friendly" or that SOAP has nothing to do with the Web.
SOAP and XML-RPC use (some people would say abuse) the HTTP POST method to
pass requests. Results are returned in an HTTP response. Since SOAP and
XML-RPC requests are in many circumstances trying to retrieve information,
the REST architecture says that you should use HTTP GET rather than HTTP
POST. To use HTTP GET, though, you would need to encode the SOAP request
information in the HTTP URL. The newest SOAP spec defines a Web-friendly
message exchange pattern (SOAP Response MEP) based on the REST architecture
and HTTP GET. See http://www.w3.org/TR/soap12-part2/#soapresmep. The client
issues an HTTP GET and receives a SOAP message in response. There are lots
of constraints on this message exchange pattern. It's used for idempotent
query functions only. It can only be used over HTTP. It doesn't support SOAP
headers. And you can't encrypt the request input message (since it's part of
the URL). The advantage of using the REST-based SOAP Response MEP is that
you can treat the SOAP service just like any other Web resource. You can
link to it, bookmark it, cache it, etc. The disadvantage of using the SOAP
Response MEP is that it doesn't work the same way as all your other SOAP
services, and it is no longer protocol independent.
|
