Related
I am creating an API project in Azure AD B2C in which I want to create a custom UI. For this requirement, I want to know which is better in both "Rest" API & "Graph" API.
Can anyone suggest to me, which is better to use?
While GraphQL is often mentioned as the replacement for REST, both tackle different problems actually.
REST, to start with, is not a protocol but just a style, which, if applied correctly, just decouples clients from servers. A server following the REST principals will therefore provide the client with any information needed to take further steps. A client initially starts without any a-priori knowledge and learns on the fly through issuing requests and processing responses.
While REST is protocol agnostic, meaning it can be build up ontop of many protocols, HTTP is probably the most prominent one. A common sample for a RESTful client is the Web browser we are all to familiar with. It will start by invoking either a bookmarked URI or invoke one entered in the address bar and progress from there on.
HTTP doesn't specify the representation the request or response has to be sent in but leaves that to clients and servers negotiating them. This helps in decoupling as both client and servers can rely on the common interface (HTTP) and only bind strongly onto the known media types used to exchange data in. A peer not being able to process a document in a certain representation (due to the lack of the respective mime type support) will indicate his other peer via a respective error message. The media type, which is just a human readable documentation of the syntax and the semantics of the data payload, is therefore the most important part in a REST architecture. It teaches a peer how to parse and interpret the received payload and to actually make sense out of it, though plenty of people still confuse REST for a JSON based HTTP API with over-engineered URIs they put to much effort in to give the URI some kind of logical sense when actually neither client nor server will interpret it anyway as they will probably use the link relation name given for the URI.
GraphQL on the other hand is a query language which gives the client the power to request specific fields and elements it wants to retrieve from the server. It is, loosely speaking, some kind of SQL for the Web. It therefore has to have knowlege on the available data beforehand which couples clients somehow to the server. If the server will rename some of the fields, the client might not be able to retrieve that kind of information further, though I'm not a GraphQL expert.
As stated above, REST is often confused for a JSON based HTTP API that allows to perform queries on directly mapped DB entries/entities. Keep in mind that REST doesn't prohibit this, though its focus is on the decoupling of peers not the retrieval aspect of some Web exposed database entries.
In the context of Azure AD and its APIs, the term REST API is used when you access the Microsoft Graph service directly. You write all the http communication code, authentication, JSON parsing etc.
The term Graph API or Graph client is a reference to the Microsoft-developed Graph Client SDK which encapsulates the above.
If there is no SDK for your platform, you need to use the REST API directly. Otherwise, I would recommend to use the SDK.
I want to know the main difference between REST and API. Sometimes I see REST API in programming documents, then is REST or API same as REST API? I would like to know more about relation between REST, API and REST API.
REST is a type of API. Not all APIs are REST, but all REST services are APIs.
API is a very broad term. Generally it's how one piece of code talks to another. In web development API often refers to the way in which we retrieve information from an online service. The API documentation will give you a list of URLs, query parameters and other information on how to make a request from the API, and inform you what sort of response will be given for each query.
REST is a set of rules/standards/guidelines for how to build a web API. Since there are many ways to do so, having an agreed upon system of structuring an API saves time in making decisions when building one, and saves time in understanding how to use one.
Other popular API paradigms include SOAP and GraphQL.
Note that the above attempts to answer the question in regards to how the terms are commonly used in web development. Roman Vottner has offered a different answer below which offers good insights into the original definition of the term REST with more technical precision than I have provided here.
REST mostly just refers to using the HTTP protocol the way it was intended. Use the GET HTTP method on a URL to retrieve information, possibly in different formats based on HTTP Accept headers. Use the POST HTTP method to create new items on the server, PUT to edit existing items, DELETE to delete them. Make the API idempotent, i.e. repeating the same query with the same information should yield the same result. Structure your URLs in a hierarchical manner etc.
REST just is a guiding principle how to use URLs and the HTTP protocol to structure an API. It says nothing about return formats, which may just as well be JSON.
That is opposed to, for example, APIs that send binary or XML messages to a designated port, not using differences in HTTP methods or URLs at all.
There is no comparison in REST and API, REST is an API type.
API, in general, is a set of protocols deployed over an application software to communicate with other software components (Like browser interacting with servers) and provide an interface to services which the application software
offers to several live consumers.
And Rest is a form of principle which an API follows in which the server provides information whatever the client desires to interact with services.
REST basically is a style of web architecture that governs the behavior of clients and servers. While API is a more general set of protocols and is deployed over the software to help it interact with some other software.
REST is only geared towards web applications. And mostly deals with HTTP requests and responses. This makes it practically usable by any programming language and easy to test.
API is an acronym for Application Programming Interface and defines a set of structures (i.e. classes) one has to implement in order to interact with a service the API was exposed for. APIs usually expose operations that can be invoked including any required or supported arguments as well as the expected responses. Classical examples here are Corba IDL, SOAP or RMI in the Java ecosystem but also RPC-like usages of Web systems specified in documentation like Swagger or OpenAPI.
REST (REpresentational State Transfer) on the contrary was specified by Fielding in his doctoral thesis where he analyzed how the whole user interactions occurs on the Web. He realized that on the Web only a transport protocol, a naming scheme for stuff as well as a well defined exchanged format is needed to exchange messages or documents. These three parts therefore define the interface to interact with peers in such a ecosystem. The transport layer is covered by HTTP while the naming scheme is defined by URI/IRI. Contrary to traditional RPC protocols which usually only support one syntax, REST is actually independent from a particular syntax. To upkeep interoperability both client and server though need do negotiate about it, which HTTP itself supports through the Accept request and Content-Type response headers. As long as client and server support HTTP, URI/IRI and a set of negotiated representation formats, defined by backing hypermedia capable media-types, they will be able to interact with each other. In a more narrow sense REST therefore has no API other than HTTP, URI/IRI and the respective media types.
However, things are unfortunately not that easy. Most people unfortunately understand something very different in terms of REST or REST API. While URIs should not convey any semantics itself, after all they are just pointers to a resource, plenty of programmers attribute more importance to URIs than they should. Some clients i.e. will attempt to extract some knowledge off of URIs or consider URIs to return responses that represent a certain type. I.e. it may seem natural to consider an URI such as https://api.acme.org/users/1 to return a representation that describes a particular user of that particualar system. An external documentation may specify that a JSON structure is returned that follows a given template such as
{
"id": 1,
"firstName": "Roman",
"lastName": "Vottner",
"role": "Admin",
...
}
can be expected, however, such a thing is closer to RPC than it is to REST. Neither is the response self-descriptive, as required by REST, nor does it follow a representation format that follows a well defined media type that defines the syntax and each of the elements that may form a message. Clients therefore are usually tailor-made for exactly one particular system (or REST API if you will) and can't be used to interact with different systems out of the box without further manual integration/updates. External documentation such as OpenAPI or Swagger are used to describe the available endpoints, the payload-templates that a server will be able to process as well as the expected responses, depending on the input. These documentation therefore is the truth and thus defines the API a client can look up or even use to autogenerate stub classes to interact with the server-side, similar to SOAP.
I therefore don't agree with the answer given by dave. While for RPC systems or the common understood term of REST API his definition may be suitable, for actual REST architectures his explanation isn't fitting at all and thus, IMO at least, not correct either. REST isn't a collection of rules, standards and/or guidelines. It is a set of few constraints that just ensure that peers in such an architecture avoid coupling, support future evolution and become more robust to change.
API is basically a set of functions and procedures which allow one application to access the feature of other application
REST is a set of rules or guidelines to build a web API.
It is basically an architectural style for networked applications on the web which is limited to client-server based applications.
Read more at: https://www.freelancinggig.com/blog/2018/11/02/what-is-the-difference-between-api-and-rest-api/
I have read articles about the differences between SOAP and REST as a web service communication protocol, but I think that the biggest advantages for REST over SOAP are:
REST is more dynamic, no need to create and update UDDI(Universal Description, Discovery, and Integration).
REST is not restricted to only XML format. RESTful web services can send plain text/JSON/XML.
But SOAP is more standardized (E.g.: security).
So, am I correct in these points?
Unfortunately, there are a lot of misinformation and misconceptions around REST. Not only your question and the answer by #cmd reflect those, but most of the questions and answers related to the subject on Stack Overflow.
SOAP and REST can't be compared directly, since the first is a protocol (or at least tries to be) and the second is an architectural style. This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn't SOAP.
Pushing things a little and trying to establish a comparison, the main difference between SOAP and REST is the degree of coupling between client and server implementations. A SOAP client works like a custom desktop application, tightly coupled to the server. There's a rigid contract between client and server, and everything is expected to break if either side changes anything. You need constant updates following any change, but it's easier to ascertain if the contract is being followed.
A REST client is more like a browser. It's a generic client that knows how to use a protocol and standardized methods, and an application has to fit inside that. You don't violate the protocol standards by creating extra methods, you leverage on the standard methods and create the actions with them on your media type. If done right, there's less coupling, and changes can be dealt with more gracefully. A client is supposed to enter a REST service with zero knowledge of the API, except for the entry point and the media type. In SOAP, the client needs previous knowledge on everything it will be using, or it won't even begin the interaction. Additionally, a REST client can be extended by code-on-demand supplied by the server itself, the classical example being JavaScript code used to drive the interaction with another service on the client-side.
I think these are the crucial points to understand what REST is about, and how it differs from SOAP:
REST is protocol independent. It's not coupled to HTTP. Pretty much like you can follow an ftp link on a website, a REST application can use any protocol for which there is a standardized URI scheme.
REST is not a mapping of CRUD to HTTP methods. Read this answer for a detailed explanation on that.
REST is as standardized as the parts you're using. Security and authentication in HTTP are standardized, so that's what you use when doing REST over HTTP.
REST is not REST without hypermedia and HATEOAS. This means that a client only knows the entry point URI and the resources are supposed to return links the client should follow. Those fancy documentation generators that give URI patterns for everything you can do in a REST API miss the point completely. They are not only documenting something that's supposed to be following the standard, but when you do that, you're coupling the client to one particular moment in the evolution of the API, and any changes on the API have to be documented and applied, or it will break.
REST is the architectural style of the web itself. When you enter Stack Overflow, you know what a User, a Question and an Answer are, you know the media types, and the website provides you with the links to them. A REST API has to do the same. If we designed the web the way people think REST should be done, instead of having a home page with links to Questions and Answers, we'd have a static documentation explaining that in order to view a question, you have to take the URI stackoverflow.com/questions/<id>, replace id with the Question.id and paste that on your browser. That's nonsense, but that's what many people think REST is.
This last point can't be emphasized enough. If your clients are building URIs from templates in documentation and not getting links in the resource representations, that's not REST. Roy Fielding, the author of REST, made it clear on this blog post: REST APIs must be hypertext-driven.
With the above in mind, you'll realize that while REST might not be restricted to XML, to do it correctly with any other format you'll have to design and standardize some format for your links. Hyperlinks are standard in XML, but not in JSON. There are draft standards for JSON, like HAL.
Finally, REST isn't for everyone, and a proof of that is how most people solve their problems very well with the HTTP APIs they mistakenly called REST and never venture beyond that. REST is hard to do sometimes, especially in the beginning, but it pays over time with easier evolution on the server side, and client's resilience to changes. If you need something done quickly and easily, don't bother about getting REST right. It's probably not what you're looking for. If you need something that will have to stay online for years or even decades, then REST is for you.
REST vs SOAP is not the right question to ask.
REST, unlike SOAP is not a protocol.
REST is an architectural style and a design for network-based software architectures.
REST concepts are referred to as resources. A representation of a resource must be stateless. It is represented via some media type. Some examples of media types include XML, JSON, and RDF. Resources are manipulated by components. Components request and manipulate resources via a standard uniform interface. In the case of HTTP, this interface consists of standard HTTP ops e.g. GET, PUT, POST, DELETE.
#Abdulaziz's 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 principle.
Stateless
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.
Cacheable
Cache constraints may be used, thus enabling response data to be marked as cacheable or not-cacheable. 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 Principles for more details on REST and the above stated bullets.
EDIT: update content based on comments
SOAP (Simple Object Access Protocol) and REST (Representation State Transfer) both are beautiful in their way. So I am not comparing them. Instead, I am trying to depict the picture, when I preferred to use REST and when SOAP.
What is payload?
When data is sent over the Internet, each unit transmitted includes both header information and the actual data being sent. The header identifies the source and destination of the packet, while the actual data is referred to as the payload. In general, the payload is the data that is carried on behalf of an application and the data received by the destination system.
Now, for example, I have to send a Telegram and we all know that the cost of the telegram will depend on some words.
So tell me among below mentioned these two messages, which one is cheaper to send?
<name>Arin</name>
or
"name": "Arin"
I know your answer will be the second one although both representing the same message second one is cheaper regarding cost.
So I am trying to say that, sending data over the network in JSON format is cheaper than sending it in XML format regarding payload.
Here is the first benefit or advantages of REST over SOAP. SOAP only support XML, but REST supports different format like text, JSON, XML, etc. And we already know, if we use Json then definitely we will be in better place regarding payload.
Now, SOAP supports the only XML, but it also has its advantages.
Really! How?
SOAP relies on XML in three ways
Envelope – that defines what is in the message and how to process it.
A set of encoding rules for data types, and finally the layout of the procedure calls and responses gathered.
This envelope is sent via a transport (HTTP/HTTPS), and an RPC (Remote Procedure Call) is executed, and the envelope is returned with information in an XML formatted document.
The important point is that one of the advantages of SOAP is the use of the “generic” transport but REST uses HTTP/HTTPS. SOAP can use almost any transport to send the request but REST cannot. So here we got an advantage of using SOAP.
As I already mentioned in above paragraph “REST uses HTTP/HTTPS”, so go a bit deeper on these words.
When we are talking about REST over HTTP, all security measures applied HTTP are inherited, and this is known as transport level security and it secures messages only while it is inside the wire but once you delivered it on the other side you don’t know how many stages it will have to go through before reaching the real point where the data will be processed. And of course, all those stages could use something different than HTTP.So Rest is not safer completely, right?
But SOAP supports SSL just like REST additionally it also supports WS-Security which adds some enterprise security features. WS-Security offers protection from the creation of the message to it’s consumption. So for transport level security whatever loophole we found that can be prevented using WS-Security.
Apart from that, as REST is limited by it's HTTP protocol so it’s transaction support is neither ACID compliant nor can provide two-phase commit across distributed transnational resources.
But SOAP has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources.
I am not drawing any conclusion, but I will prefer SOAP-based web service while security, transaction, etc. are the main concerns.
Here is the "The Java EE 6 Tutorial" where they have said A RESTful design may be appropriate when the following conditions are met. Have a look.
Hope you enjoyed reading my answer.
REST(REpresentational State Transfer)
REpresentational State of an Object is Transferred is REST i.e. we don't send Object, we send state of Object.
REST is an architectural style. It doesn’t define so many standards like SOAP. REST is for exposing Public APIs(i.e. Facebook API, Google Maps API) over the internet to handle CRUD operations on data. REST is focused on accessing named resources through a single consistent interface.
SOAP(Simple Object Access Protocol)
SOAP brings its own protocol and focuses on exposing pieces of application logic (not data) as services. SOAP exposes operations. SOAP is focused on accessing named operations, each operation implement some business logic. Though SOAP is commonly referred to as web services this is misnomer. SOAP has a very little if anything to do with the Web. REST provides true Web services based on URIs and HTTP.
Why REST?
Since REST uses standard HTTP it is much simpler in just about ever way.
REST is easier to implement, requires less bandwidth and resources.
REST permits many different data formats where as SOAP only permits XML.
REST allows better support for browser clients due to its support for JSON.
REST has better performance and scalability. REST reads can be cached, SOAP based reads cannot be cached.
If security is not a major concern and we have limited resources. Or we want to create an API that will be easily used by other developers publicly then we should go with REST.
If we need Stateless CRUD operations then go with REST.
REST is commonly used in social media, web chat, mobile services and Public APIs like Google Maps.
RESTful service return various MediaTypes for the same resource, depending on the request header parameter "Accept" as application/xml or application/json for POST and /user/1234.json or GET /user/1234.xml for GET.
REST services are meant to be called by the client-side application and not the end user directly.
ST in REST comes from State Transfer. You transfer the state around instead of having the server store it, this makes REST services scalable.
Why SOAP?
SOAP is not very easy to implement and requires more bandwidth and resources.
SOAP message request is processed slower as compared to REST and it does not use web caching mechanism.
WS-Security: While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features.
WS-AtomicTransaction: Need ACID Transactions over a service, you’re going to need SOAP.
WS-ReliableMessaging: If your application needs Asynchronous processing and a guaranteed level of reliability and security. Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying.
If the security is a major concern and the resources are not limited then we should use SOAP web services. Like if we are creating a web service for payment gateways, financial and telecommunication related work then we should go with SOAP as here high security is needed.
source1
source2
IMHO you can't compare SOAP and REST where those are two different things.
SOAP is a protocol and REST is a software architectural pattern. There is a lot of misconception in the internet for SOAP vs REST.
SOAP defines XML based message format that web service-enabled applications use to communicate each other over the internet. In order to do that the applications need prior knowledge of the message contract, datatypes, etc..
REST represents the state(as resources) of a server from an URL.It is stateless and clients should not have prior knowledge to interact with server beyond the understanding of hypermedia.
First of all: officially, the correct question would be web services + WSDL + SOAP vs REST.
Because, although the web service, is used in the loose sense, when using the HTTP protocol to transfer data instead of web pages, officially it is a very specific form of that idea. According to the definition, REST is not "web service".
In practice however, everyone ignores that, so let's ignore it too
There are already technical answers, so I'll try to provide some intuition.
Let's say you want to call a function in a remote computer, implemented in some other programming language (this is often called remote procedure call/RPC). Assume that function can be found at a specific URL, provided by the person who wrote it. You have to (somehow) send it a message, and get some response. So, there are two main questions to consider.
what is the format of the message you should send
how should the message be carried back and forth
For the first question, the official definition is WSDL. This is an XML file which describes, in detailed and strict format, what are the parameters, what are their types, names, default values, the name of the function to be called, etc. An example WSDL here shows that the file is human-readable (but not easily).
For the second question, there are various answers. However, the only one used in practice is SOAP. Its main idea is: wrap the previous XML (the actual message) into yet another XML (containing encoding info and other helpful stuff), and send it over HTTP. The POST method of the HTTP is used to send the message, since there is always a body.
The main idea of this whole approach is that you map a URL to a function, that is, to an action. So, if you have a list of customers in some server, and you want to view/update/delete one, you must have 3 URLS:
myapp/read-customer and in the body of the message, pass the id of the customer to be read.
myapp/update-customer and in the body, pass the id of the customer, as well as the new data
myapp/delete-customer and the id in the body
The REST approach sees things differently. A URL should not represent an action, but a thing (called resource in the REST lingo). Since the HTTP protocol (which we are already using) supports verbs, use those verbs to specify what actions to perform on the thing.
So, with the REST approach, customer number 12 would be found on URL myapp/customers/12. To view the customer data, you hit the URL with a GET request. To delete it, the same URL, with a DELETE verb. To update it, again, the same URL with a POST verb, and the new content in the request body.
For more details about the requirements that a service has to fulfil to be considered truly RESTful, see the Richardson maturity model. The article gives examples, and, more importantly, explains why a (so-called) SOAP service, is a level-0 REST service (although, level-0 means low compliance to this model, it's not offensive, and it is still useful in many cases).
Among many others already covered in the many answers, I would highlight that SOAP enables to define a contract, the WSDL, which define the operations supported, complex types, etc.
SOAP is oriented to operations, but REST is oriented at resources.
Personally I would select SOAP for complex interfaces between internal enterprise applications, and REST for public, simpler, stateless interfaces with the outside world.
Addition for:
++ A mistake that’s often made when approaching REST is to think of it as “web services with URLs”—to think of REST as another remote procedure call (RPC) mechanism, like SOAP, but invoked through plain HTTP URLs and without SOAP’s hefty XML namespaces.
++ On the contrary, REST has little to do with RPC. Whereas RPC is service oriented and focused on actions and verbs, REST is resource oriented, emphasizing the things and nouns that comprise an application.
A lot of these answers entirely forgot to mention hypermedia controls (HATEOAS) which is completely fundamental to REST. A few others touched on it, but didn't really explain it so well.
This article should explain the difference between the concepts, without getting into the weeds on specific SOAP features.
REST API
RESTful APIs are the most famous type of API. REST stands REpresentational State Transfer.
REST APIs are APIs that follow standardized principles, properties, and constraints.
You can access resources in the REST API using HTTP verbs.
REST APIs operate on a simple request/response system. You can send a request using these HTTP methods:
GET
POST
PUT
PATCH
DELETE
TRACE
OPTIONS
CONNECT
HEAD
Here are the most common HTTP verbs
GET (read existing data)
POST (create a new response or data)
PATCH (update the data)
DELETE (delete the data)
The client can make requests using HTTP verbs followed by the endpoint.
The endpoint (or route) is the URL you request for. The path determines the resource you’re requesting.
When you send a request to an endpoint, it responds with the relevant data, generally formatted as JSON, XML, plain text, images, HTML, and more.
REST APIs can also be designed with many different endpoints that return different types of data. Accessing multiple endpoints with a REST API requires various API calls.
An actual RESTful API follows the following five constraints:
Client-Server Architecture
The client requests the data from the server with no third-party interpretation.
Statelessness
Statelessness means that every HTTP request happens in complete isolation. Each request contains the information necessary to service the request. The server never relies on information from previous requests. There’s no state.
Cacheability
Responses can be explicitly or implicitly defined as cacheable or non-cacheable to improve scalability and performance. For example, enabling the cache of GET requests can improve the response times of requests for resource data.
Layering
Different layers of the API architecture should work together, creating a scalable system that is easy to update or adjust.
Uniform Interface
Communication between the client and the server must be done in a standardized language that is independent of both. This improves scalability and flexibility.
REST APIs are a good fit for projects that need to be
Flexible
Scalable
Fast
SOAP API
SOAP is a necessary protocol that helped introduce the widespread use of APIs.
SOAP is the acronym for Simple Object Access Protocol.
SOAP is a standardized protocol that relies on XML to make requests and receive responses.
Even though SOAP is based on XML, the SOAP protocol is still in wide usage.
SOAP APIs make data available as a service and are typically used when performing transactions involving multiple API calls or applications where security is the primary consideration.
SOAP was initially developed for Microsoft in 1998 to provide a standard mechanism for integrating services on the internet regardless of the operating system, object model, or programming language.
The “S” in SOAP stands for Simple, and for a good reason — SOAP can be used with less complexity as it requires less coding in the app layer for transactions, security, and other functions.
SOAP has three primary characteristics:
Extensibility of SOAP API
SOAP allows for extensions that introduce more robust features, such as Windows Server Security, Addressing, and more.
Neutrality of SOAP API
SOAP is capable of operating over a wide range of protocols, like UDP, JMS, SMTP, TCP, and HTTP.can operate.
Independence of SOAP API
SOAP API responses are purely based on XML. Therefore SOAP APIs are platform and language independent.
Developers continue to debate the pros and cons of using SOAP and REST. The best one for your project will be the one that aligns with your needs.
SOAP APIs remain a top choice for corporate entities and government organizations that prioritize security, even though REST has largely dominated web applications.
SOAP is more secure than REST as it uses WS-Security for transmission along with Secure Socket Layer
SOAP also has more excellent transactional reliability, which is another reason why SOAP historically has been favored by the banking industry and other large entities.
What is REST
REST stands for representational state transfer, it's actually an architectural style for creating Web API which treats everything(data or functionality) as recourse.
It expects; exposing resources through URI and responding in multiple formats and representational transfer of state of the resources in stateless manner. Here I am talking about two things:
Stateless manner: Provided by HTTP.
Representational transfer of state: For example if we are adding an employee. .
into our system, it's in POST state of HTTP, after this it would be in GET state of HTTP, PUT and DELETE likewise.
REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.SOAP uses services interfaces to expose the business logic. REST uses URI to expose business logic.
REST is not REST without HATEOAS. This means that a client only knows the entry point URI and the resources are supposed to return links the client should follow. Those fancy documentation generators that give URI patterns for everything you can do in a REST API miss the point completely. They are not only documenting something that's supposed to be following the standard, but when you do that, you're coupling the client to one particular moment in the evolution of the API, and any changes on the API have to be documented and applied, or it will break.
HATEOAS, an abbreviation for Hypermedia As The Engine Of Application State, is a constraint of the REST application architecture that distinguishes it from most other network application architectures. The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. By contrast, in some service-oriented architectures (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL).
Reference 1
Reference 2
Although SOAP and REST share similarities over the HTTP protocol, SOAP is a more rigid set of messaging patterns than REST. The rules in SOAP are relevant because we can’t achieve any degree of standardization without them. REST needs no processing as an architecture style and is inherently more versatile. In the spirit of information exchange, both SOAP and REST depend on well-established laws that everybody has decided to abide by.
The choice of SOAP vs. REST is dependent on the programming language you are using the environment you are using and the specifications.
To answer this question it’s useful to understand the evolution of the architecture of distributed applications from simple layered architectures, to object & service based, to resources based, & nowadays we even have event based architectures. Most large systems use a combination of styles.
The first distributed applications had layered architectures. I'll assume everyone here knows what layers are. These structures are neatly organized, and can be stacks or cyclical structures. Effort is made to maintain a unidirectional data flow.
Object-based architectures evolved out of layered architectures and follow a much looser model. Here, each component is an object (often called a distributed object). The objects interact with one another using a mechanism similar to remote procedure calls - when a client binds to a distributed object it loads an implementation of the objects interface into its address space. The RPC stub can marshal a request & receive a response. Likewise the objects interface on the server is an RPC style stub. The structure of these object based systems is not as neatly organized, it looks more like an object graph.
The interface of a distributed object conceals its implementation. As with layered components, if the interface is clearly defined the internal implementation can be altered - even replaced entirely.
Object-based architectures provide the basis for encapsulating services. A service is provided by a self-contained entity, though internally it can make use of other services. Gradually object-based architectures evolved into service-oriented architectures (SOAs).
With SOA, a distributed application is composed of services. These services can be provided across administrative domains - they may be available across the web (i.e. a storage service offered by a cloud provider).
As web services became popular, and more applications started using them, service composition (combining services to form new ones) became more important. One of the problems with SOA was that integrating different services could become extremely complicated.
While SOAP is a protocol, its use implies a service oriented architecture. SOAP attempted to provide a standard for services whereby they would be composable and easily integrated.
Resource-based architectures were a different approach to solving the integration problems of SOA. The idea is to treat the distributed system as a giant collection of resources that are individually managed by components.
This led to the development of RESTful architectures. One thing that characterizes RESTful services is stateless execution. This is different than SOA where the server maintains the state.
So… how do service-specific interfaces, as provided by service-oriented architectures (including those that use SOAP) compare with resource-based architecture like REST?
While REST is simple, it does not provide a simple interface for complex communication schemes. For example, if you are required to use transactions REST is not appropriate, it is better to keep the complex state encapsulated on the server than have the client manage the transaction. But there are many scenarios where the orthogonal use of resources in RESTful architectures greatly simplifies integration of services in what would otherwise mean an explosion of service interfaces. Another tradeoff is resource-based architectures put more complexity on the client & increase traffic over the network while service-based increase the complexity of the server & tax its memory & CPU resources.
Some people have also mentioned common HTTP services or other services that do not satisfy the requirements of RESTful architecture or SOAP. These too can be categorized as either service-based or resource-based. These have the advantage of being simpler to implement. You'd only use such an approach if you knew your service will never need to be integrated across administrative domains since this makes no attempt at fixing the integration issues that arise.
These sorts of HTTP-based services, especially Pseudo-RESTful services are still the most common types. Implementing SOAP is complicated and should only be used if you really need it - i.e. you need a service that's easily integrated across domains and you want it to have a service-interface. There are still cases where this is needed. A true RESTful service is also difficult to implement, though not as difficult as SOAP.
What does it make Restful webservices different from the other Web Services like SOAP?
The debate over web services is by no means complete, but there are some elements that stand out.
RESTful web services are a 'family' of web services. Some would call it an architecture.
RESTful web services use the HTTP protocol to perform requests from a web service. They use the HTTP verbs: GET, POST, PUT and DELETE (and others, sometimes). The requests themselves are to URLs which represent resources... sometimes the requests will contain data in the body that could by HTML, JSON, binary data or other.
A purely RESTful web service only requires the URL and the HTTP verb to describe the requested action... the body data is usually a payload to be involved in the requested action... it should not dictate the requested action
SOAP, on the other hand, is actually a protocol. It is usually transported over HTTP, but the HTTP request is just a method to get the SOAP packet to the necessary handler. The contents of the SOAP request describes what the client wants performed. It contains all the necessary information.
They are two very different ways of implementing Web Services. If you ask the question "Which is better" you'll probably get strong opinions from both sides. I suggest you investigate further and make up your own mind.
A RESTful web service (also called a RESTful web API) is a simple web service implemented using HTTP and the principles of REST. Such a web service can be thought about as a collection of resources. The definition of such a web service can be thought of as comprising three aspects:
The base URI for the web service, such as http://example.com/resources/
The MIME type of the data supported by the web service. This is often JSON, XML or YAML but can be any other valid MIME type.
The set of operations supported by the web service using HTTP methods (e.g., POST, GET, PUT or DELETE).
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on eXtensible Markup Language (XML) as its message format, and usually relies on other Application Layer protocols (most notably Remote Procedure Call (RPC) and HTTP) for message negotiation and transmission. This XML based protocol consists of three parts:
an envelope - which defines what is in the message and how to process it -
a set of encoding rules for expressing instances of application-defined datatypes,
and a convention for representing procedure calls and responses.
references:
http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services
http://en.wikipedia.org/wiki/SOAP
By the way, a simple google search could provide answers for you...
Ok there is a wealth of knowledge in Stack Overflow on this topic.
I think the best article that articulates the spirit of REST and how it compares against technologies like SOAP is How I explained REST to my wife.
Unlike SOAP, REST is not a standard it's more of an approach that's centred around Resources and things you can do to resources. The HTTP verbs GET, POST, PUT and DELETE are typical actions that you can apply against any resource. SOAP is a standard that ignores these verbs and has invented a more comprehensive protocol that works on top of the most popular verb HTTP POST for maximum interoperability. Most of the time this added complexity is unnecessary and a simple HTTP GET request for a resource would normally suffice over what could be potentially 1KB+ of SOAP+XML to achieve an equivalent result.
You can also check out Roy Fielding's blog (the inventor of REST) for more information about what it means.
RESTful services focus on speed and simplicity, eliminating the overhead of SOAP for the simple transactions that many web services require. However, a service implemented in this way is very HTTP-specific, and you'll have a hard time making use of it outside of that context.
SOAP services offer more out-of-the-box features, the most important (imho, of course) of which is discovery. The ability to add a reference to a SOAP service in just about any dev environment and have it automatically generate a proxy class that will hide the underlying HTTP complexities, even to the point of serializing non-trivial types, is very, very useful.
I feel that both of these approaches to web service development have their place. For AJAX requirements that don't require anything complex, I tend to implement as an HTTP handler (ASP.NET). Anything that needs to be called from another application, or from multiple places within the same app, I implement as a SOAP service because of the protocol encapsulation that it provides, as well as the ability to call the use the underlying object without the HTTP overhead where it makes sense.
1) REST is more simple and easy to use than SOAP
2) REST uses HTTP protocol for producing or consuming web services while SOAP uses XML.
3) REST is lightweight as compared to SOAP and preferred choice in mobile devices and PDA's.
4) REST supports different format like text, JSON and XML while SOAP only support XML.
5) REST web services call can be cached to improve performance.
Can somebody explain what is REST and what is SOAP in plain english? And how Web Services work?
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.
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.
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.
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)
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.
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-*
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
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!
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.
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.
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.
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.
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.
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