REST (representational state transfer)

This definition is part of our Essential Guide: Guide to SOA and the cloud
Contributor(s): Moriah Sargent and David Linthicum

REST (REpresentational State Transfer) is an architectural style, and an approach to communications that is often used in the development of Web services. The use of REST is often preferred over the more heavyweight SOAP (Simple Object Access Protocol) style because REST does not leverage as much bandwidth, which makes it a better fit for use over the Internet. The SOAP approach requires writing or using a provided server program (to serve data) and a client program (to request data).

REST'S decoupled architecture, and lighter weight communications between producer and consumer, make REST a popular building style for cloud-based APIs, such as those provided by Amazon, Microsoft, and Google. When Web services use REST architecture, they are called RESTful APIs (Application Programming Interfaces) or REST APIs.

REST architecture involves reading a designated Web page that contains an XML file. The XML file describes and includes the desired content. Once dynamically defined, consumers may access the interface.

REST, which typically runs over HTTP (Hypertext Transfer Protocol), has several architectural constraints:

1. Decouples consumers from producers

2. Stateless existence

3. Able to leverage a cache

4. Leverages a layered system

5. Leverages a uniform interface

REST is often used in mobile applications, social networking Web sites, mashup tools, and automated business processes. The REST style emphasizes that interactions between clients and services is enhanced by having a limited number of operations (verbs). Flexibility is provided by assigning resources (nouns) their own unique Universal Resource Identifiers (URIs). Because each verb has a specific meaning (GET, POST, PUT and DELETE), REST avoids ambiguity.

There are some downsides. In the world of REST, there is no direct support for generating a client from server-side-generated metadata. SOAP is able to support this with Web Service Description Language (WSDL).

REST provides the following advantages, specifically advantages over leveraging SOAP:

  • RESTful Web services are easy to leverage by most tools, including those that are free and inexpensive. REST is becoming the dial tone for systems interaction, including the use of RESTful Web services, which are, for the most part, the way cloud providers externalize their cloud services.
  • SOAP services are much harder to scale than RESTful services. Thus, REST is often chosen as the architecture for services that are exposed via the Internet (like Facebook, MySpace, Twitter, and most public cloud providers).
  • The learning curve seems to be reduced. Developers are able to make use of REST from within applications faster than they can with SOAP. This saves time, which saves money.
  • REST uses a smaller message format than SOAP. SOAP uses XML for all messages, which makes the message size much larger, and thus less efficient. This means REST provides better performance, as well as lowers costs over time. Moreover, there is no intensive processing required, thus it’s much faster than traditional SOAP.
  • REST is designed for use over the Open Internet/Web. This is a better choice for Web scale applications, and certainly for cloud-based platforms.

Moving forward, REST is likely to continue its growth as enterprises seek to provide open and well-defined interfaces for application and infrastructure services. The growth of public and private cloud computing is driving much of this demand, and will continue to drive growth into the future.


This was last updated in December 2014

Next Steps

Buying mobile app dev tools? Here are some factors to consider

Continue Reading About REST (representational state transfer)



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Thanks for sharing the information!!!
Glad this definition could be of help, Sandeep6933! Let us know if you are looking for more information on REST or have any question about it.
Do you think REST is easier to use than SOAP?
Not particularly, no. Can you give me good reasons why I should think so? What, for instance, of decoupling? In what way does REST provide decoupling of consumers and providers?
This feels like a technology/religion discussion (VHS vs. Betamax) when the reality is the market has moved past SOAP in almost every instance where the web, modern applications or devices is involved. RESTful APIs have become the new default. 
Gralgrathor, while not necessarily easier, I've heard some developers say they prefer SOAP because they think it's more secure than REST. Thoughts?
Yes, Brian, I've heard a lot of developers talking about RESTful APIs. What are some of the benefits you've experienced with it?
Speaking for myself, I find the ReSTful API approach to be easier and quicker to work with compared to the SOAP tests I had done in the past. Having said that, the last few years has been almost entirely based around ReST API, so I don't have recent enough experience with SOAP to give a fair assessment. 
I have been working and listing about the REST Api since i have been in this field. Not as much experienced but can definitely vote for REST over SOAP. 
Why do you prefer REST over SOAP, Harish426?
According to SOAP's Wikipedia page, "The verbosity of the protocol led to the domination in the field by services leveraging the REST architectural style."
I can see how this may somehow be truth. However, I honestly prefer REST simply because of the huge amount of documentation, articles, tutorials and tools related to REST APIs creation. It's simply easier to get information about REST. Obviously, I might have just missed all the data related to SOAP.
I feel that REST is easier to be consumed, while SOAP might be easier to build.  I'm not sure how I'd prove that statement though.
The thing about SOAP is that a programmer typically never interacts with SOAP directly.  Instead, you access a WSDL file and a Class library.  You create some objects, set some properties, and invoke a method.  I've been coding SOAP calls for years and have never, ever seen a SOAP XML stream.  The WSDL file makes SOAP very easy to use, and, in practice, you can do most of what you need to do with very little programming.  Even better, SOAP returns objects, not JSON or XML, so on return from your SOAP call, you simply access object properties and methods.

As far as I know, REST has nothing comparable to a WSDL file (please let me know if I am wrong), and a lot of RESTful interfaces do not come with any kind of class library support.  You end up having to build URIs and parse JSON or XML.  That may not be particularly hard, but the point I want to make is that people who work with SOAP don't typically work with SOAP itself .. they deal with a highly abstracted object representation that is very easy to use.

From what I can tell, easier or harder to work with shouldn't really play into the decision of choosing one over the other. It depends on use case. If you have a legacy, primarily on-premise system where extremely tight security is your number one priority, you might want to go with SOAP. If your goal is to build lightweight mobile apps as fast as possible, I don't think there's anyone who wouldn't tell you to go with REST.
RESTful is lot easier.SOAP has big requests and reponses in the form of xml, really unpreferable.
Only reason for SOAP is "secure"
Definitely Restful API. But I think one part of the idea based on what kind of developer you are. Static or Dynamic. I think the Static community, Java and C#, might prefer SOAP, and Dynamic, Ruby...etc prefer REST.

I think REST can be secure too, but it doesn't come with the API, and require the develops to build the security in the application. But for the user of the API, REST should be much easier and lightweight. 
Yes, REST is easier than SOAP.
  1. REST is more dynamic, no need for creating and updating UDDI.

  2. REST is not restricted to XML format. REST web services can send plain text, JSON, and also XML.

REST is almost always going to be faster. The main advantage of SOAP is that it provides a mechanism for services to describe themselves to clients, and to advertise their existence. REST is much more lightweight and can be implemented using almost any tool, leading to lower bandwidth and shorter learning curve. However, the clients have to know what to send and what to expect.
I am seeing a lot of new web services are implemented using a REST style architecture these days rather than a SOAP one. Lets step back a second and explain what REST is. What is a REST Web Service? The acronym REST stands for Representational State Transfer, this basically means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET, to delete it, you then might use a POST, PUT, or DELETE to modify the object (in practice most of the services use a POST for this).
Excellent article
Excellent article on REST. Thank you so much for posting.
It should perhaps be noted that REST can also communicate with a JSON object instead of just XML.

hi I am fairly new to custom coding and have primarily work with plugins or outsourced when needed I am try to understand if you need input an api key for rest to enable it and i notice it said open web i correct to assume this means you cannot use this on https or is the article just stating the mode of transportation for the information.

Best practice for creating a new REST server.

Not as much experienced but can definitely vote for REST over SOAP. 
People, let's not make some confusions...
When you say REST is easy to be consumed, probably you think of JSON answers. Yeah, that's easy only from browsers, but not all communication in the world is between web servers and browsers. There are thin clients for line of business applications, there are compiled executables that more easily and safely parse XML.
Plus that:
- in a regular SOAP response, you can have the data type of those members embedded as well, while in JSON not;
- and JSON is only a particularly type of data a REST service can return. What if it returns XML (indicated by the content_type)? Then parsing is exactly as in SOAP.

Then every SOAP service has its description automatically available, the WSDL. On a REST API, you depend on somebody telling you how what are the parameters you send and the structure of the data coming back, while on SOAP you automatically see all that in the WSDL.
An example:
- a REST API that returns {FirstName:'John', LastName:'Doe', Address:null} when you ask ?person=3. You don't know how a real address looks like, you will need the company division in Netherlands to tell you what that address looks like or give you people Ids to test with until you get one with a real address. You also don't know that there's another URL parameter nullAddress=false unless the guys in Netherlands tell you so;
- a SOAP API automatically has the WSDL in which you can see all the "methods", all the parameters, all the return types, everything. In the WSLD you see that Address is an object of some type containing objects of other types and so on, stuff you can't infer from looking at a REST response. And, based on that WSDL, your IDE generates code you can use to call that WS and get back real objects like Person.Address.Main and Person.Address.Secondary.Street. Automatically.

About the size of the data while in-between server and client... Sorry but a REST service sends less data only when you want JSON. If it serves back XML (which would be easy to parse on a thin client, for example), the payload is the same. Then, as both of them usually go over HTTP, the content is compressed anyway so the payload is quite the same.

About the parameters being easily sent in the URL as ?person=13... Yes, no problem, unless the parameters you send are bigger. When you send a whole Person or array of Person as parameter, then you kinda send a POST payload so again, not a difference.

About the processing on the server... Serializing the data to XML or to JSON is no different.

So let's not hurry and declare that REST is everything... No, it's only as long as you're talking simple data between browsers and web servers. But when you talk complex data structures, automatically-generated (so typed, so testable) clients that every Average Joe can use to safely consume a server API, it's still SOAP.


File Extensions and File Formats