REST (REpresentational State Transfer)

Contributor(s): Kevin Ferguson, Cameron McKenzie

REST (REpresentational State Transfer) is an architectural style for developing web services. REST is popular due to its simplicity and the fact that it builds upon existing systems and features of the internet's Hypertext Transfer Protocol (HTTP) in order to achieve its objectives, as opposed to creating new standards, frameworks and technologies.

Advantages of REST

A primary benefit of using REST, both from a client and server's perspective, is REST-based interactions happen using constructs that are familiar to anyone who is accustomed to using the internet's HTTP.

An example of this arrangement is REST-based interactions all communicate their status using standard HTTP status codes. So, a 404 means a requested resource wasn't found; a 401 code means the request wasn't authorized; a 200 code means everything is OK; and a 500 means there was an unrecoverable application error on the server.

Similarly, details such as encryption and data transport integrity are solved not by adding new frameworks or technologies, but instead by relying on well-known Secure Sockets Layer (SSL) encryption and Transport Layer Security (TLS). So, the entire REST architecture is built upon concepts with which most developers are already familiar.

REST is also a language-independent architectural style. REST-based applications can be written using any language, be it Java, Kotlin, .NET, AngularJS or JavaScript. As long as a programming language can make web-based requests using HTTP, it is possible for that language to be used to invoke a RESTful API or web service. Similarly, RESTful web services can be written using any language, so developers tasked with implementing such services can choose technologies that work best for their situation.

The other benefit of using REST is its pervasiveness. On the server side, there are a variety of REST-based frameworksfor helping developers create RESTful web services, including RESTlet and Apache CXF. From the client side, all of the new JavaScript frameworks, such as JQuery, Node.js, Angular and EmberJS, all have standard libraries built into their APIs that make invoking RESTful web services and consuming the XML- or JSON-based data they return a relatively straightforward endeavor.

Disadvantages of REST

The benefit of REST using HTTP constructs also creates restrictions, however. Many of the limitations of HTTP likewise turn into shortcomings of the REST architectural style. For example, HTTP does not store state-based information between request-response cycles, which means REST-based applications must be stateless and any state management tasks must be performed by the client.

Similarly, since HTTP doesn't have any mechanism to send push notifications from the server to the client, it is difficult to implement any type of services where the server updates the client without the use of client-side polling of the server or some other type of web hook.

From an implementation standpoint, a common problem with REST is the fact that developers disagree with exactly what it means to be REST-based. Some software developers incorrectly consider anything that isn't SOAP-based to be RESTful. Driving this common misconception about REST is the fact that it is an architectural style, so there is no reference implementation or definitive standard that will confirm whether a given design is RESTful. As a result, there is discourse as to whether a given API conforms to REST-based principles.

Alternatives to REST

Alternate technologies for creating SOA-based systems or creating APIs for invoking remote microservices include XML over HTTP (XML-RPC), CORBA, RMI over IIOP and the Simple Object Access Protocol (SOAP).

Each technology has its own set of benefits and drawbacks, but the compelling feature of REST that sets it apart is the fact that, rather than asking a developer to work with a set of custom protocols or to create a special data format for exchanging messages between a client and a server, REST insists the best way to implement a network-based web service is to simply use the basic construct of the network protocol itself, which in the case of the internet is HTTP.

This is an important point, as REST is not intended to apply just to the internet; rather, its principles are intended to apply to all protocols, including WEBDAV and FTP.


The two competing styles for implementing web services are REST and SOAP. The fundamental difference between the two is the philosophical approach the two have to remotely invocations.

REST takes a resource-based approach to web-based interactions. With REST, you locate a resource on the server, and you choose to either update that resource, delete it or get some information about it.

With SOAP, the client doesn't choose to interact directly with a resource, but instead calls a service, and that service mitigates access to the various objects and resources behind the scenes.

SOAP has also built a large number of frameworks and APIs on top of HTTP, including the Web Services Description Language (WSDL), which defines the structure of data that gets passed back and forth between the client and the server.

Some problem domains are served well by the ability to stringently define the message format or can benefit from using various SOAP-related APIs, such as WS-Eventing, WS-Notification and WS-Security. There are times when HTTP cannot provide the level of functionality an application might require, and in these cases, using SOAP is preferable. 


Most people are familiar with the way URLs and URIs work on the web. A RESTful approach to developing applications asserts that requesting information about a resource should be as simple as invoking its URL.

For example, if a client wanted to invoke a web service that listed all of the quizzes available here at TechTarget, the URL to the web service would look something like this:

When invoked, the web service might respond with the following JSON string listing all of the available quizzes, one of which is about DevOps:

{ "quizzes" : [ "Java", "DevOps", "IoT"] }

To get the DevOps quiz, the web service might be called using the following URL:

Invoking this URL would return a JSON string listing all of the questions in the DevOps quiz. To get an individual question from the quiz, the number of the question would be added to the URL. So, to get the third question in the DevOps quiz, the following RESTful URL would be used:

Invoking that URL might return a JSON string such as the following:

{ "Question" : {"query":"What is your DevOps role?", "optionA":"Dev", "optionB":"Ops"} }

As you can see, the REST URLs in this example are structured in a logical and meaningful way that identifies the exact resource being requested.

JSON and XML REST data formats

The example above shows JSON used as the data exchange format for the RESTful interaction. The two most common data exchange formats are JSON and XML, and many RESTful web services can use both formats interchangeably, as long as the client can request the interaction to happen in either XML or JSON.

Note that while JSON and XML are popular data exchange formats, REST itself does not put any restrictions on what the format should be. In fact, some RESTful web services exchange binary data for the sake of efficiency. This is another benefit to working with REST-based web services, as the software architect is given a great deal of freedom in terms of how best to implement a service.

REST and the HTTP methods

The example above only dealt with accessing data.

The default operation of HTTP is GET, which is intended to be used when getting data from the server. However, HTTP defines a number of other methods, including PUT, POST and DELETE.

The REST philosophy asserts that to delete something on the server, you would simply use the URL for the resource and specify the DELETE method of HTTP. For saving data to the server, a URL and the PUT method would be used. For operations that are more involved than simply saving, reading or deleting information, the POST method of HTTP can be used.

History of REST

REST was first coined by computer scientist Roy Fielding in his year-2000 Ph.D. dissertation at the University of California, titled Architectural Styles and the Design of Network-based Software Architectures.

Chapter 5 of the dissertation, "Representational State Transfer (REST)," described Fielding's beliefs about how best to architect distributed hypermedia systems. Fielding noted a number of boundary conditions that describe how REST-based systems should behave. These conditions are referred to as REST constraints, with four of the key constraints described below:

  • Use of a uniform interface (UI). As stated earlier, resources in REST-based systems should be uniquely identifiable through a single URL, and only by using the underlying methods of the network protocol, such as DELETE, PUT and GET with HTTP, should it be possible to manipulate a resource.
  • Client-server-based.In a REST-based system, there should be a clear delineation between the client and the server. UI and request-generating concerns are the domain of the client. Meanwhile, data access, workload management and security are the domain of the server. This separation allows loose coupling between the client and the server, and each can be developed and enhanced independent of the other.
  • Stateless operations.All client-server operations should be stateless, and any state management that is required should happen on the client, not the server.
  • RESTful resource caching. The ability to cache resources between client invocations is a priority in order to reduce latency and improve performance. As a result, all resources should allow caching unless an explicit indication is made that it is not possible.

Developing REST APIs in Java

To accommodate the growing popularity of REST-based systems, a number of frameworks have arisen to assist developers in the creation of RESTful web services.

Some of the more popular open source frameworks for creating Java-based, RESTful web services include Apache CXF, Jersey, Restlet, Apache Wink, Spring Data and JBoss' RESTeasy.

The general approach of each of these frameworks is to help developers build RESTful web services using semantics with which Java developers are familiar, including Java Platform (Enterprise Edition), the Servlet API and annotations, while at the same time, offering built-in classes and methods that make it easier to keep in line with the basic tenets of REST.

REST and the IoT

Given the near ubiquity of REST APIs and the explosive number of devices on the Internet of Things (IoT), it seems to be a perfect pairing. Compact formats based on JSON, EXI and CBOR (Concise Binary Object Representation), a JSON offshoot, are used and RESTful APIs are likewise compact.

In an IoT scheme, devices work in a client-server relationship. In that relationship, devices can act as clients, servers or both. Devices can act as a client and initiate contact with a directory, such as the CoRE Resource Directory, or another device. Devices can also act in the capacity of an origin server or resource, such as to serve as a sensor, serving temperatures or other status indicators.

Yet, as noted above, all client-server operations using REST should be stateless, and any state management that is required should happen on the client, not the server. That means all messages must contain all the information to process it, independent from previous messages.

Two things have helped REST become popular with IoT developers. Firstly, REST is already pervasive, well-understood and replicable. Secondly, because the data requested from resources in IoT tends to be simple, such as a sensor's current reading, and static, such as a manufacturer's device description, REST, which leverages the internet's HTTP, is a natural fit.

Learn more about REST in the video below:

This was last updated in July 2019

Next Steps

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

Continue Reading About REST (REpresentational State Transfer)

Dig Deeper on REST, SOAP and API protocols

Join the conversation


Send me notifications when other members comment.

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.
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.
The 'S' in SOAP represents the word "simple." Truth be told, SOAP is not necessarily simple. It can be very complicated, and the complication is gratuitous. REST is easy to implement and the only challenge I face is that sometimes people do not understand or appreciate the purpose of the REST Verbs. My vote is for REST.

A few more details: I have worked on both SOAP and REST. I have worked with both consumers and providers, because my domain is middle-ware. When building a SOAP provider, I have had to build the WSDL file, along with the XSDs, and that certainly is not something I would call easy or convenient. With REST, only the XSD has to be created. Moreover, it is easy to transmit JSON over REST, and not so easy over SOAP, unless one were to place the entire JSON string inside an XML.
I've never washed my hands with REST
As far as I know, REST has nothing compared to the WSDL file (please tell me if I am wrong), and many RESTful interfaces do not come with any class library support. You are finally building URI and Pars JSON or XML. This can not be particularly difficult, but the point I want to make is that the people who work with soap generally do not work with SOAP. They are with a highly abstract object representation. Work that is very easy to use.