REST and SOAP

Question

Can somebody explain what is REST and what is SOAP in plain english? And how Web Services work?

Answer 1

You can try reading here: http://www.petefreitag.com/item/431.cfm

Answer 2

I think that this is as easy as I can explain it. Please, anyone is welcome to correct me or add to this.

SOAP is a message format used by disconnected systems (like across the internet) to exchange information / data. It does with XML messages going back and forth.

Web services transmit or receive SOAP messages. They work differently depending on what language they are written in.

Answer 3

Both methods are used by many of the large players. It's a matter of preference. My preference is REST because it's simpler to use and understand.

SOAP:

• SOAP builds an XML protocol on top of HTTP or sometimes TCP/IP.
• SOAP describes functions, and types of data.
• SOAP is a successor of XML-RPC and is very similar, but describes a standard way to communicate.
• Several programming languages have native support for SOAP, you typically feed it a web service URL and you can call its web service functions without the need of specific code.
• Binary data that is sent must be encoded first into a format such as base64 encoded.
• Has several protocols and technologies relating to it: WSDL, XSDs, SOAP, WS-Addressing

Representational state transfer (REST):

• REST need not be over HTTP but most of my points below will have an HTTP bias.
• REST is very lightweight, it says wait a minute, we don't need all of this complexity that SOAP created.
• Typically uses normal HTTP methods instead of a big XML format describing everything. For example to obtain a resource you use HTTP GET, to put a resource on the server you use HTTP PUT. To delete a resource on the server you use HTTP DELETE.
• REST is a very simple in that it uses HTTP GET, POST and PUT methods to update resources on the server.
• REST typically is best used with Resource Oriented Architecture (ROA). In this mode of thinking everything is a resource, and you would operate on these resources.
• As long as your programming language has an HTTP library, and most do, you can consume a REST HTTP protocol very easily.
• Binary data or binary resources can simply be delivered upon their request.

There are endless debates on REST vs SOAP on google.

My favorite is this one.

Answer 4

A very in plain english version of Rest

Answer 5

I like Brian R. Bondy's answer. I just wanted to add that Wikipedia provides a clear description of REST. The article distinguishes it from SOAP.

REST is an exchange of state information, done as simply as possible.

SOAP is a message protocol that uses XML.

One of the main reasons that many people have moved from SOAP to REST is that the WS-* (called WS splat) standards associated with SOAP based web services are EXTREMELY complicated. See wikipedia for a list of the specifications. Each of these specifications is very complicated.

EDIT: for some reason the links are not displaying correctly. REST = http://en.wikipedia.org/wiki/REST

WS-* = http://en.wikipedia.org/wiki/WS-*

Answer 6

SOAP and REST both refer to ways for different systems to talk to each other.

REST does this using techniques that resemble the communication that your browser has with web servers: using GET to request a web page, POSTing in form fields, etc.

SOAP provides for something similar but does everything through sending blocks of XML back and forth. Another key component of SOAP is WSDL which is an XML document that describes what functions and data elements are supported. WSDLs can be used to programmatically "discover" what functions are supported as well as to generate programming code stubs.

Answer 7

The problem with SOAP is that it is in conflict with the ideals behind the HTTP stack. Any middleware should be able to work with HTTP requests without understanding the content of the request or response, but for example a regular HTTP caching server won't work with SOAP requests without knowing only which parts of the SOAP content matter for caching. SOAP just uses HTTP as a wrapper for its own communications protocol, like a proxy.