Representational state transfer (REST) and Simple Object Access Protocol (SOAP)

Asked 16/10, 2008 at 19:24 Answered 4/2, 2015 at 16:34

737

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

Griseofulvin answered 16/10, 2008 at 19:24 Comment(6)

You must read this PDF for understanding REST and SOAP web services. – Briarroot 9/12, 2013 at 7:30

You can check this blog javapapers.com/web-service/rest-vs-soap – Powel 27/12, 2013 at 11:6

Can I recommend reading Fielding's Dissertation on the subject of REST: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm – Flickinger 10/9, 2014 at 13:5

possible duplicate of SOAP or REST for Web Services? – Cloaca 29/10, 2014 at 21:8

@PhilipCouling I wouldn't call any PhD dissertation plain English... – Decimate 9/2, 2017 at 21:4

you can use these tow links: #30582030 AND dotnettricks.com/learn/webapi/… – Animal 5/8, 2020 at 13:58

1590

Simple explanation about SOAP and REST

SOAP - "Simple Object Access Protocol"

SOAP is a method of transferring messages, or small amounts of information, over the Internet. SOAP messages are formatted in XML and are typically sent using HTTP (hypertext transfer protocol).

Rest - Representational state transfer

Rest is a simple way of sending and receiving data between client and server and it doesn't have very many standards defined. You can send and receive data as JSON, XML or even plain text. It's light weighted compared to SOAP.

enter image description here

Martainn answered 24/1, 2012 at 7:2 Comment(7)

SOAP is much more than sending data in an envelope. However, it's mostly used to send a BLOB to the server, ignoring whatever features SOAP also provides. So basically, most people use SOAP like REST with a standard envelope. (SOAP is a good example of over-engineering) – Riccardo 15/4, 2013 at 14:9

SOAP does in NO WAY force one to use HTTP or XML. HTTP and XML are the things defined in WS-I for interoperability, but one can also send POJOs over JMS. The thing is, that the programmer does not need to care: The service bus manages the transport and the encoding. – Bergmans 15/4, 2013 at 17:26

For every complex problem there is an answer that is clear, simple, and wrong. --H. L. Mencken – Bozovich 19/7, 2013 at 14:4

@Morten - Just visited techexplainedwithmartinlawrence.com. It is now a camping site. For some reason I find that fantastic. +1 internets to you. – Skirr 26/11, 2013 at 16:39

The example was epic! – Lazos 22/4, 2014 at 14:47

KEEP READING. While this answer is entertaining @Pavel's answer below is much more complete. – Prolate 29/7, 2014 at 22:9

To be fair the guy did ask for an anser in "in plain english". This is about as plain as one can get. Good entertaining answer. – Schall 18/11, 2015 at 12:36

327

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.

Simple Object Access Protocol (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. Update 27 Nov 2013: Paul Prescod's site appears to have gone offline and this article is no longer available, copies though can be found on the Wayback Machine or as a PDF at CiteSeerX.

Fastigiate answered 16/10, 2008 at 19:33 Comment(13)

REST has nothing to do with HTTP (it is protocol independent), and XML is fine to use within a RESTful architecture. GET/POST/PUT/DELETE is simply using HTTP correctly - necessary for REST but not sufficient. – Citizenry 20/7, 2009 at 17:51

How can REST client know what methods and types he may use? In SOAP there is WSDL from which many tools can generate classes and methods. – Divert 23/7, 2010 at 12:10

@jlp: It is up to the REST client developer to properly use the exposed REST interface. – Fastigiate 23/7, 2010 at 13:4

@Divert - The methods a REST developer can use over HTTP are simply GET, PUT, POST and DELETE (and maybe HEAD); simple as that. That is a benefit, not a limitation is and one of the things that makes REST so powerful when compared to an RPC protocol like SOAP. – Platitudinize 8/4, 2011 at 4:41

REST simply says 'use a uniform interface'. Since the HTTP Interface [GET, POST, PUT, DELETE, (UPDATE, HEAD)] became the 'uniform interface' of the web, REST (on the web) is somehow dependent on HTTP in my opinion! – Alimentary 22/6, 2012 at 9:51

SOAP does not need to be over HTTP and XML, but mostly it uses that for interoperability. For instance, see w3.org/TR/soapjms/#introduction-outofscope – Bergmans 15/4, 2013 at 17:29

> How can REST client know what methods and types he may use? You're supposed to return a certain map of available action urls from your request handler, which client may use to look as "where to go next from there". I'm not sure if there's anything but convention for the types. – Cordwood 16/4, 2013 at 10:46

types are defined by... content-type headers! They're part of the HTTP interface along with the standard verbs. – Shantae 15/5, 2013 at 19:8

zacstewart.com/2012/04/14/http-options-method.html - the OPTIONS header can be used to help define which verbs a specific resource url supports. – Uncleanly 17/5, 2013 at 9:8

developer.mozilla.org/en-US/docs/HTTP/… - also useful reading about preflighted requests – Uncleanly 17/5, 2013 at 9:9

@Citizenry REST is VERY MUCH dependent on HTTP. To say otherwise is insane. The REST approach is solidly defined via the HTTP RFC (by the W3C TAG). There is no other specification of it other than a doctoral dissertation by Roy Fielding of UC Irvine. See: en.wikipedia.org/wiki/Representational_state_transfer – Chaise 26/9, 2013 at 20:41

Hi @Brenden, thanks for your comment. You're responding to something I wrote 4 years ago though - I agree with its dependency on HTTP. – Citizenry 30/9, 2013 at 1:35

REST only works over HTTP and HTTPS. WS/SOAP works over HTTP, HTTPS, SMTP, XMPP, etc. – Powel 27/12, 2013 at 11:8

268

REST

I understand the main idea of REST is extremely simple. We have used web browsers for years and we have seen how easy, flexible, performing, etc web sites are. HTML sites use hyperlinks and forms as the primary means of user interaction. Their main goal is to allow us, clients, to know only those links that we can use in the current state. And REST simply says 'why not use the same principles to drive computer rather than human clients through our application?' Combine this with the power of the WWW infrastructure and you'll get a killer tool for building great distributed applications.

Another possible explanation is for mathematically thinking people. Each application is basically a state machine with business logic actions being state transitions. The idea of REST is to map each transition onto some request to a resource and provide clients with links representing transitions available in the current state. Thus it models the state machine via representations and links. This is why it's called REpresentational State Transfer.

It's quite surprising that all answers seem to focus either on message format, or on HTTP verbs usage. In fact, the message format doesn't matter at all, REST can use any one provided that the service developer documents it. HTTP verbs only make a service a CRUD service, but not yet RESTful. What really turns a service into a REST service are hyperlinks (aka hypermedia controls) embedded into server responses together with data, and their amount must be enough for any client to choose the next action from those links.

Unfortunately, it's rather difficult to find correct info on REST on the Web, except for the Roy Fielding's thesis. (He's the one who derived REST). I would recommend the 'REST in Practice' book as it gives a comprehensive step-by-step tutorial on how to evolve from SOAP to REST.

SOAP

This is one of the possible forms of RPC (remote procedure call) architecture style. In essence, it's just a technology that allows clients call methods of server via service boundaries (network, processes, etc) as if they were calling local methods. Of course, it actually differs from calling local methods in speed, reliability and so on, but the idea is that simple.

Compared

The details like transport protocols, message formats, xsd, wsdl, etc. don't matter when comparing any form of RPC to REST. The main difference is that an RPC service reinvents bicycle by designing it's own application protocol in the RPC API with the semantics that only it knows. Therefore, all clients have to understand this protocol prior to using the service, and no generic infrastructure like caches can be built because of proprietary semantics of all requests. Furthermore, RPC APIs do not suggest what actions are allowed in the current state, this has to be derived from additional documentation. REST on the other hand implies using uniform interfaces to allow various clients to have some understanding of API semantics, and hypermedia controls (links) to highlight available options in each state. Thus, it allows for caching responses to scale services and making correct API usage easily discoverable without additional documentation.

In a way, SOAP (as any other RPC) is an attempt to tunnel through a service boundary treating the connecting media as a black box capable of transmitting messages only. REST is a decision to acknowledge that the Web is a huge distributed information system, to accept the world as is and learn to master it instead of fighting against it.

SOAP seems to be great for internal network APIs, when you control both the server and the clients, and while the interactions are not too complex. It's more natural for developers to use it. However, for a public API that is used by many independent parties, is complex and big, REST should fit better. But this last comparison is very fuzzy.

Update

My experience has unexpectedly shown REST development to be more difficult than SOAP. At least for .NET. While there are great frameworks like ASP.NET Web API, there's no tooling that would automatically generate client-side proxy. Nothing like 'Add Web Service Reference' or 'Add WCF Service Reference'. One has to write all serialization and service querying code by hand. And man, that's lots of boilerplate code. I think REST development needs something similar to WSDL and tooling implementation for each development platform. In fact, there seems to be a good ground: WADL or WSDL 2.0, but neither of the standards seems to be well-supported.

Update (Jan 2016)

Turns out there is now a wide variety of tools for REST API definition. My personal preference is currently RAML.

How Web Services work

Well, this is a too broad question, because it depends on the architecture and technology used in the specific web service. But in general, a web service is simply some application in the Web that can accept requests from clients and return responses. It's exposed to the Web, thus it's a web service, and it's typically available 24/7, that's why it's a service. Of course, it solves some problem (otherwise why would someone ever use a web service) for its clients.

Uproarious answered 19/9, 2012 at 18:41 Comment(8)

This should be the most upvoted answer by far! I have a sense of humour, but it's depressing when comedy answers on StackOverflow trump well considered ones. – Ungrounded 14/1, 2014 at 3:26

@TomHall I guess this situation is a bit specific to REST - RPC discussion, not only on SO. I guess that is the reason we don't have reasonable tooling for REST clients. At least on .NET, implementing a REST service client has proved to be way more difficult than generating a SOAP service reference. One has to write the proxy classes by hand. For some reason people think about REST as if there were no rules at all, while the original idea on the contrary puts much more restrictions on the architecture. I wish the community understood REST - then we could expect better tooling and adoption. – Uproarious 23/1, 2014 at 13:43

@PavelGatilov This answer is great. I had read other REST explanations and never "got it" that the driving principle is that possible state transitions are part of the response. The fact that you took the time to reflect back on your experience and acknowlede the difficulties is also of great value to everyone of us. – Impropriate 29/3, 2014 at 0:35

Excellent answer. I wonder how long it will take for REST-I to develop now with it starting to look more and more SOAP like with RAML , Swagger and WADL slogging it out for the de-facto standard of being REST. I found the lack of tooling on REST compared to SOAP a major pain when developing some rather sensitive and complex financial systems. Both REST and SOAP are awesome when used correctly. My grandfather always said you can use a screwdriver to hammer in a nail but it aint going to work that well. Same applies here. Right tool for the job mentality not my way is the only way.\ – Ignatzia 23/7, 2017 at 20:52

Oh I also favor RAML and I prefer top down development, the one thing I found most disturbing about REST was the lack of a structured top down approach. I like to think before I act . – Ignatzia 23/7, 2017 at 21:2

I don’t know for how long but there are currently multiple ways to consume Rest-Apis as .Net Developer. There is Add ->REST API Client on same level as Add-> Service Reference and the classic add Service Reference help got reworked so it can add OpenAPI and others too. I know this is a Old Post but it still appears on top of Searches – Stereoscope 10/11, 2020 at 10:26

@Pavlov - Thanks for the great answer. Would you mind explaining the difference between REST API and HTTP API? – Jot 12/11, 2020 at 16:32

@AwsAnurag, I am not sure I know what exactly HTTP API is. I suspect different people might be implying different things by this term. Therefore, I don't think there is a generic answer. I would recommend you to post a separate question and explain the context where you encounter the term better - to get a meaningful answer. – Uproarious 12/5, 2021 at 10:21

This is the simplest explanation you will ever find.

This article takes a husband to wife narrative, where the husband explains to his wife about REST, in pure layman terms. Must read!

how-i-explained-rest-to-my-wife (original link)
how-i-explained-rest-to-my-wife (2013-07-19 working link)

Multiplicate answered 13/7, 2012 at 7:33 Comment(1)

The part about polymorphism is beautiful. – Cointon 1/3, 2014 at 10:38

SOAP - Simple Object Access Protocol is a protocol!

REST - REpresentational State Transfer is an architectural style!

SOAP is an XML protocol used to transfer messages, typically over HTTP

REST and SOAP are arguably not mutually exclusive. A RESTful architecture might use HTTP or SOAP or some other communication protocol. REST is optimized for the web and thus HTTP is a perfect choice. HTTP is also the only protocol discussed in Roy Fielding's paper.

Although REST and SOAP are clearly very different, the question does illuminate the fact that REST and HTTP are often used in tandem. This is primarily due to the simplicity of HTTP and its very natural mapping to RESTful principles.

Fundamental REST Principles

Client-Server Communication

Client-server architectures have a very distinct separation of concerns. All applications built in the RESTful style must also be client-server in princple.

Stateless

Each each client request to the server requires that its state be fully represented. The server must be able to completely understand the client request without using any server context or server session state. It follows that all state must be kept on the client. We will discuss stateless representation in more detail later.

Cacheable

Cache constraints may be used, thus enabling response data to to be marked as cacheable or not-cachable. Any data marked as cacheable may be reused as the response to the same subsequent request.

Uniform Interface

All components must interact through a single uniform interface. Because all component interaction occurs via this interface, interaction with different services is very simple. The interface is the same! This also means that implementation changes can be made in isolation. Such changes, will not affect fundamental component interaction because the uniform interface is always unchanged. One disadvantage is that you are stuck with the interface. If an optimization could be provided to a specific service by changing the interface, you are out of luck as REST prohibits this. On the bright side, however, REST is optimized for the web, hence incredible popularity of REST over HTTP!

The above concepts represent defining characteristics of REST and differentiate the REST architecture from other architectures like web services. It is useful to note that a REST service is a web service, but a web service is not necessarily a REST service.

See this blog post on REST Design Principals for more details on REST and the above stated bullets.

Carlacarlee answered 14/3, 2014 at 20:28 Comment(2)

Just thinking it would be totally HATEOAS to request a RESTful resource and receive a response which includes a link to WSDL describing what operations are available on that resource in its current state. Although I guess that a RESTful SOAP web service would be a bit like skipping over RMM level 3 and going straight to level 4. :) – Wittol 29/5, 2014 at 16:29

This is the best answer for reflecting that it is not either/or with REST and SOAP. +1 for noting that REST is a style. – Handgun 1/7, 2014 at 17:28

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

Ketonuria answered 16/10, 2008 at 19:47 Comment(7)

SOAP is NOT a protocol. SOAP is about encoding. SOAP is used over many protocols: JMS, http, ... – Bergmans 15/4, 2013 at 17:23

@Bergmans You mean other than the fact that it stands for "Simple Object Access Protocol"? Also, do you know what a protocol is? A protocol is basically a set of rules over how two or more things should communicate, which is exactly what SOAP is for, a standard way to communicate. – Lactose 15/4, 2013 at 22:7

@Demizey Do you refer to the most recent version of SOAP, which is 1.2? w3.org/TR/soap12-part1 "SOAP" now stands in its own as in practice it is NOT used as protocol. "SOAP 1.2 will not spell out the acronym." (w3.org/TR/2007/REC-soap12-part0-20070427/#L4697) Are you aware of the layers of the Web Service stack as (e.g.) described in the Book "Web Services Platform Architecture: Soap, Wsdl, Ws-Policy, Ws-Addressing, Ws-Bpel, Ws-Reliable Messaging, and More"? Transport-layer communication is done via HTTP, SMTP, RMI/IIOP, JMS or others. SOAP is used in the messaging layer – Bergmans 16/4, 2013 at 10:0

Along the line of a SOAP connection, many intermediaries may sit inbetween. This is enabled by the SOAP processing model, which distinguished between the ultimate SOAP receiver and zero or more SOAP intermediaries. The transport protocol may change inbetween. The SOAP message path also enables transparent implementation of the EAI patterns (eaipatterns.com) – Bergmans 16/4, 2013 at 11:10

It's still a messaging protocol. – Lactose 16/4, 2013 at 15:29

SOAP uses XML infoset, which allows, for instance, to use CSV or JSON to transfer data. msdn.microsoft.com/en-us/library/aa302293.aspx / cxf.apache.org/docs/json-support.html. Even though, it's not widely used in practice. – Bergmans 17/4, 2013 at 11:15

Still SOAP is not used as protocol in Service-Oriented Architecture. Note that "Access Protocol" occurs only once in the SOAP 1.2 specification. At the point where SOAP 1.1 appears at the "Informative Reference" section. – Bergmans 17/11, 2020 at 10:5

Both SOAP webservices and REST webservices can use the HTTP protocol and other protocols as well (just to mention SOAP can be the underlying protocol of REST). I will talk only about the HTTP protocol related SOAP and REST, because this is the most frequent usage of them.

SOAP

SOAP ("simple" object access protocol) is a protocol (and a W3C standard). It defines how to create, send and process SOAP messages.

SOAP messages are XML documents with a specific structure: they contain an envelope which contains the header and the body section. The body contains the actual data - we want to send - in an XML format. There are two encoding styles, but we usually choose literal, which means that our application or its SOAP driver does the XML serialization and unserialization of the data.
SOAP messages travel as HTTP messages with SOAP+XML MIME subtype. These HTTP messages can be multipart, so optionally we can attach files to SOAP messages.
Obviously we use a client-server architecture, so the SOAP clients send requests to the SOAP webserices and the services send back responses to the clients. Most of the webservices use a WSDL file to describe the service. The WSDL file contains the XML Schema (XSD hereafter) of the data we want to send and the WSDL binding which defines how the webservice is bound to the HTTP protocol. There are two binding styles: RPC and document. By the RPC style binding the SOAP body contains the representation of an operation call with the parameters (HTTP requests) or the return values (HTTP response). The parameters and return values are validated against the XSD. By the document style binding the SOAP body contains an XML document which is validated against the XSD. I think the document binding style is better suited to event based systems, but I never used that binding style. The RPC binding style is more prevalent, so most people use SOAP for XML/RPC purposes by distributed applications. The webservices usually find each other by asking an UDDI server. UDDI servers are registries which store the location of the webservices.

SOAP RPC

So the - in my opinion - most prevalent SOAP webservice uses RPC binding style and literal encoding style and it has the following properties:

It maps URLs to operations.
It sends messages with SOAP+XML MIME subtype.
It can have a server side session store, there are no constraints about that.
The SOAP client drivers use the WSDL file of the service to convert the RPC operations into methods. The client side application communicates with the SOAP webservice by calling these methods. So most of the SOAP clients break by interface changes (resulting method names and/or parameter changes).
It is possible to write SOAP clients which won't break by interface changes using RDF and find operations by semantics, but semantic webservice are very rare and they don't necessarily have a non breaking client (I guess).

REST

REST (representational state transfer) is an architecture style which is described in the dissertation of Roy Fielding. It does not concern about protocols like SOAP does. It starts with a null architecture style having no constraints and defines the constraints of the REST architecture one by one. People use the term RESTful for webservices which fulfill all of the REST constraints, but according to Roy Fielding, there are no such things as REST levels. When a webservice does not meet with every single REST constraint, then it is not a REST webservice.

REST constraints

Client - server architecture - I think this part is familiar to everyone. The REST clients communicate with the REST webservices, the webservices maintain the common data - resource state hereafter - and serve it to the clients.
Stateless - The "state transfer" part of the abbreviation: REST. The clients maintain the client state (session/application state), so the services must not have a session storage. The clients transfer the relevant part of the client state by every request to the services which respond with the relevant part of the resource state (maintained by them). So requests don't have context, they always contain the necessary information to process them. For example by HTTP basic auth the username and the password is stored by the client, and it sends them with every request, so authentication happens by every request. This is very different from regular webapplications where authentication happens only by login. We can use any client side data storage mechanism like in-memory(javascript), cookies, localStorage, and so on... to persist some parts of the client state if we want. The reason of the statelessness constraint, that the server scales well - even by very high load (millions of users) - when it does not have to maintain the session of every single client.
Cache - The response must contain information about it can be cached by the client or not. This improves scalability further.
Uniform interface
- Identification of resources - REST resource is the same as RDF resource. According to Fielding if you can name something, then it can be a resource, for example: "the current local weather" can be a resource, or "your mobile phone" can be a resource, or "a specific web document" can be a resource. To identify a resource you can use resource identifiers: URLs and URNs (for example ISBN number by books). A single identifier should belong only to a specific resource, but a single resource can have many identifiers, which we frequently exploit for example by pagination with URLs like https://example.com/api/v1/users?offset=50&count=25. URLs have some specifications, for example URLs with the same pathes but different queries are not identical, or the path part should contain the hierarhical data of the URL and the query part should contain the non-hierarchical data. These are the basics of how to create URLs by REST. Btw. the URL structure does matter only for the service developers, a real REST client does not concern with it. Another frequently asked question is API versioning, which is an easy one, because according to Fielding the only constant thing by resource is semantics. If the semantics change, then you can add a new version number. You can use classical 3 number versioning and add only the major number to the URLs (https://example.com/api/v1/). So by backward compatible changes nothing happens, by non-backward compatible changes you will have a non-backward compatible semantics with a new API root https://example.com/api/v2/. So the old clients won't break, because they can use the https://example.com/api/v1/ with the old semantics.
- Manipulation of resources through representations - You can manipulate the data related to resources (resource state) by sending the intended representation of the resources - along with the HTTP method and the resource identifier - to the REST service. For example if you want to rename a user after marriage, you can send a PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"} request where the {name: "Mrs Smith"} is a JSON representation of the intended resource state, in other words: the new name. This happens vica-versa, the service sends representations of resources to the clients in order to change their states. For example if we want to read the new name, we can send a GET https://example.com/api/v1/users/1?fields="name" retrieval request, which results in a 200 ok, {name: "Mrs Smith"} response. So we can use this representation to change the client state, for example we can display a "Welcome to our page Mrs Smith!" message. A resource can have many representations depending on the resource identifier (URL) or the accept header we sent with the request. For example we can send an image of Mrs Smith (probably not nude) if image/jpeg is requested.
- Self-descriptive messages - Messages must contain information about how to process them. For example URI and HTTP method, content-type header, cache headers, RDF which describes the meaning of the data, etc... It is important to use standard methods. It is important to know the specification of the HTTP methods. For example GET means retrieving information identified by the request URL, DELETE means asking the server to delete the resource identified by the given URL, and so on... HTTP status codes have a specification as well, for example 200 means success, 201 means the a new resource has been created, 404 means that the requested resource was not found on the server, etc... Using existing standards is an important part of REST.
- Hypermedia as the engine of application state (HATEOAS hereafter) - Hypermedia is a media type which can contain hyperlinks. By the web we follow links - described by a hypermedia format (usually HTML) - to achieve a goal, instead of typing the URLs into the addres bar. REST follows the same concept, the representations sent by the service can contain hyperlinks. We use these hyperlinks to send requests to the service. With the response we get data (and probably more links) which we can use to build the new client state, and so on... So that's why hypermedia is the engine of application state (client state). You probably wonder how do clients recognize and follow the hyperlinks? By humans it is pretty simple, we read the title of the link, maybe fill input fields, and after that just a single click. By machines we have to add semantics to the links with RDF (by JSON-LD with Hydra) or with hypermedia specific solutions (for example IANA link relations and vendor specific MIME types by HAL+JSON). There are many machine readable XML and JSON hypermedia formats, just a short list of them:
  - XHTML
  - ATOM+XML
  - RDF+XML
  - HAL+XML
  - HAL+JSON
  - JSON-LD
  - RDF+JSON
  - Siren
  - Collection+JSON
  Sometimes it is hard to choose...
Layered system - We can use multiple layers between the clients and the services. None of them should know about all of these additonal layers, just of layer right next to it. These layers can improve scalability by applying caches and load balancing or they can enforce security policies.
Code on demand - We can send back code which extends the functionality of the client, for example javascript code to a browser. This is the only optional constraint of REST.

REST webservice - SOAP RPC webservice differences

So a REST webservice is very different from a SOAP webservice (with RPC binding style and literal encoding style)

It defines an uniform interface (intead of a protocol).
It maps URLs to resources (and not operations).
It sends messages with any MIME types (instead of just SOAP+XML).
It has a stateless communication, and so it cannot have a server side session storage. (SOAP has no constraint about this)
It serves hypermedia and the clients use links contained by that hypermedia to request the service. (SOAP RPC uses operation bindings described in the WSDL file)
It does not break by URL changes only by semantics changes. (SOAP RPC clients without using RDF semantics break by WSDL file changes.)
It scales better than a SOAP webservice because of its stateless behavior.

and so on...

A SOAP RPC webservice does not meet all of the REST constraints:

client-server architecture - always
stateless - possible
cache - possible
uniform interface - never
layered system - never
code on demand (optional) - possible

Angleworm answered 7/9, 2014 at 3:42 Comment(0)

Well I'll begin with the second question: What are Web Services? , for obvious reasons.

WebServices are essentially pieces of logic(which you may vaguely refer to as a method) that expose certain functionality or data. The client implementing(technically speaking, consuming is the word) just needs to know what are the parameter(s) the method is going to accept and the type of data it is going to return(if at all it does).

The following Link says it all about REST & SOAP in an extremely lucid manner.

REST vs SOAP

If you also want to know when to choose what (REST or SOAP), all the more reason to go through it!

Noleta answered 11/10, 2012 at 7:39 Comment(0)

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.

Bengt answered 4/7, 2009 at 6:9 Comment(4)

That has nothing to do with REST, that's just 'correct usage of HTTP' – Citizenry 20/7, 2009 at 19:39

HTTP itself is the best example of a RESTful system. – Bengt 21/7, 2009 at 7:10

@Bengt No, HTTP is not, it basically has no notion of hypermedia. But HTML with its hyperlinks and forms is a RESTful system. Actually, it was the prototype of the REST 'specification' – Uproarious 19/9, 2012 at 19:3

SOAP does NOT force you to use XML encoding. XML encoding is only used if a service offers interoperability. Internally, POJOs may be sent with no encoding in XML. – Bergmans 15/4, 2013 at 17:24

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.

Citizenry answered 20/7, 2009 at 17:54 Comment(3)

It's against the ideals, and we've only just noticed that. It's been around since 1998 or so, and we're only just picking up on it. Damn, we're stupif! – Phallus 24/7, 2009 at 15:0

No John, "we" as the informed web developer community, have known all along. It's only the slow ones and the ones that are coming out of CS school without a proper education that have just cottoned on. – Urana 10/5, 2013 at 8:32

"We" are not all web developers. Some of us are just trying to get things done the best way possible and don't care if we're "not using the full potential of the web". – Phallus 1/2, 2014 at 2:40

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.

Damnify answered 16/10, 2008 at 19:30 Comment(3)

Elaborate on what you mean by "they work differently". SOAP is typically employed as a way for different systems written in different or unknown technologies to talk using a common comprehensible language with clearly defined parameters. – Synagogue 15/4, 2013 at 17:25

Web services work differently depending on what language they are written in. Just an unimportant extra detail. – Damnify 15/4, 2013 at 17:34

Ok, I wasn't sure if you were implying there was something inhibiting interoperability. – Synagogue 16/4, 2013 at 15:54

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

Thurifer answered 11/6, 2013 at 10:13 Comment(0)

SOAP – "Simple Object Access Protocol"

SOAP is a slight of transferring messages, or little amounts of information over the Internet. SOAP messages are formatted in XML and are typically sent controlling HTTP.

REST – "REpresentational State Transfer"

REST is a rudimentary proceed of eventuality and receiving information between fan and server and it doesn't have unequivocally many standards defined. You can send and accept information as JSON, XML or even plain text. It's light weighted compared to SOAP.

Osborn answered 4/2, 2015 at 16:34 Comment(0)

-4

SOAPbased Web Services In short, the SOAPbased Services model views the world as an ecosystem of coequal peers that cannot control each other, but have to work together by honoring published contracts. It's a valid model of the messy real world, and the metadata based contracts form the SOAP Service Interface.

we can still associate SOAP with XMLbased Remote Procedure Calls, but SOAPbased Web Services technology has emerged into a flexible and powerful messaging model.

SOAP assumes all systems are independent and no system has any knowledge of the internals of another and internal functionality. The most such systems can do is send messages to one another and hope they will be acted upon. Systems publish contracts that they undertake to honor, and other systems rely upon these contracts to exchange messages with them.

Contracts between systems are collectively called metadata, and comprise service descriptions, the message exchange patterns supported and the policies governing qualities of service (a service may need to be encrypted, reliably delivered, etc.) A service description, in turn, is a detailed specification of the data (message documents) that will be sent and received by the system. The documents are described using an XML description language like XML Schema Definition. As long as all systems honor their published contracts, they can inter operate, and changes to the internals of systems never affect any other. Every system is responsible for translating its own internal implementations to and from its contracts

REST - REpresentational State Transfer. The physical protocol is HTTP. Basically, REST is that all distinct resources on the web that are uniquely identifiable by a URL. All operations that can be performed on these resources can be described by a limited set of verbs (the “CRUD” verbs) which in turn map to HTTP verbs.

REST's is much less “heavyweight” than SOAP.

Working of web service

Geaghan answered 19/10, 2013 at 6:46 Comment(1)

-1 Almost everything you say is incorrect. SOAP does not contain a description. The WSDL does. WSDL is an XML format - it doesn't "run" on any protocol. SOAP does not require middleware. REST is not "the second generation of web services". WADL is not a standard. See en.wikipedia.org/wiki/Web_Application_Description_Language. – Phallus 1/2, 2014 at 2:37

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++