REST: REpresentational State Transfer. That's what it means and where it comes from, but what is it and why should we care? Hopefully, this article will take care of that part.

You hear a lot about REST today. Of course, that does depend on where you're standing, who you're talking with, and whether you're paying attention. But if you're standing in the right spot, talking to web-oriented developers, and actually listening to what they're saying, you'll hear a lot about REST. And that's good because REST is becoming the default architecture to use for web apps today, particularly mobile. But what is REST, and how can you use it?

Let's start by saying that when you create a web app, you're going to use web services to interact with the web resources that are being held on the server. How you build those web services will be very important in how the app works, and REST is one way in which you can build web services.

Maybe the best way to describe REST is as an "architecture style" (courtesy of Dr. M. Elkstein). It's not an architecture per se, but a way or "style" of building your web services. It's not standardized as SOAP is. There's no W3C document describing what you need to do for a service to be "RESTful," but there are tons of articles and books devoted to it. REST is most often compared to SOAP, which was originally developed for Microsoft and is another way to consume or support web services.

Technically, there are three main architecture styles that you can use to support your need for web information: RPC, SOA or SOAP, and REST.

• Of these, Remote Procedure Call (RPC) is the oldest and approaches the task in terms of operations or activities.
• Service-Oriented Architecture (SOA) and SOAP (which describes the communications portion of SOA) are sometimes seen as interchangeable, and many articles will reference one or the other. We're going to refer to this implementation as SOAP. It was actually a refinement (standardization) of RPC, and it looks at things from a message or data point of view.
• REST is a relative newcomer to the arena, not in terms of actual age but in terms of people paying attention to it and the focus on resources (a web page or table element, for example).

REST was originally described in the doctorial dissertation of Dr. Roy Fielding, who was one of the developers of HTTP. In that paper, Fielding laid out very clearly what he saw as the foundational aspects of REST.

Foundational Aspects of REST

REST rests on four basic principles, and any web service that meets these criteria can be considered RESTful. Sounds very peaceful and nice, doesn't it?

First, "Representational" means that, when we access something using a RESTful web service, what we get back is just the representation of the resource we're accessing, not the actual resource. In other words, if we use a RESTful web service to access a data base, what's returned to us is an XML or JSON data stream that represents that actual database, not the database itself. I know that sounds like splitting hairs, but it's an important distinction and it allows you to specify (XML or JSON) exactly how you would like to receive the data you're accessing.

Second, "State" means that all RESTful web services will be stateless from a server point of view. Remember, there are two sides to any web service request: the client side that's making the request (that is, you) and the server side that's fulfilling the request (that is, the place where the resource you're going after resides on the web). REST requires that you not keep any information about the state of a request on the server where state information is that keeps track of what the status of the request is. In other words, every request for resources must stand alone and carry the data required to define this request. The server is not allowed to store any information that would help in this process or that could be used later. All state information is kept solely on the client side.

Third, "Transfer" refers to how the data is shared between the server and the client sides. REST is generally associated with using HTTP as the transfer method or protocol, but that's not required. You can use whatever protocol you would like, but as I said, the general method used with REST is HTTP due to its simplicity and flexibility.

OK, let's stop for a minute and look back over that because that's a mouthful and more. If there's a heart and soul to REST, it's in the facts that you get to choose both your data transfer mechanism (XML or JSON, for example) and the protocol that's used, that you're passing only a representation of the data (not the actual data itself), and that you don't keep data on the server that defines the general conversation (each REST request stands on its own without saving any information from a previous request). In the end, it provides a simple (relatively speaking) and flexible way to access resources.

Characteristics of REST

Above, we looked at the basic assumptions REST is based on, but here are some specific characteristics it has.

Everything Is a URI

Everything in a RESTful request is defined as a separate Uniform Resource Identifier (URI). Since this is the way the web is actually structured, it makes perfect, simple sense.

It also has the added benefit of not describing in the request itself, what data you're going after. For example, if you look at many sites, the URI that shows up when you make a request is the actual SQL inquiry that's used to get this information, thus providing hackers with important information on the structure of your site.

Hyperlinks Are Key

The web itself is organized and connected by means of hyperlinks. And that's the way control is handled in REST. By limiting the movement of control to actions within the resources themselves (for example, a hyperlink on a page), REST provides a simple and yet intuitive way to move from one spot to another.

Statelessness Simplifies

The fact that the server never has to keep information about a request after it is completed and then match it up with the next request that comes in from that same thread greatly simplifies the programming required on the server side and removes overhead. All of the state information resides on the client side, which has a vested interest in remembering where a given request is in the total app.

The Transport Mechanism Allows Flexibility

Because REST doesn't dictate what protocol you use, you're free to use whatever seems best to you. Granted, almost always we see HTTP being used with REST, but the reasons for that are twofold. First, REST lets you make the decision about what you will use. Second, HTTP is a very powerful yet simple protocol, utilizing four basic operations (GET, POST, PUT, and DELETE) to do all transfers, making it a natural choice if you have the option to choose.

Some Thoughts on REST Applications

REST is simple, but you need to think about a couple of things as you get ready to build a REST app.

State or Stateless

I don't want to beat this into the ground, but you have to decide which side you're on—that is, what type your app on the server is. Do you need for it to keep track of where it is, or is each request to it independent?

XML or JSON

This is something you get to decide. Some people like XML because it's the default standard for data transfer. I like JSON because it's not as tedious as XML.

Building Your URIs

Most important of all is how you build your URIs—that is, what structure they have. Since REST uses hyperlinks to these URIs to transfer control, how they're structured is very important. Here are a few tips.

• Keep them simple; keep them short.
• Be consistent. The URI should show a path, not be a random name. And by being consistent, it should be predictable—e.g., trees/deciduous/maple/sugar-maple
• Do not use embedded spaces or underscores. Dashes are better for Search Engine Optimization (SEO). Avoid mixed case since that's a good way to introduce errors. Do not include extensions.
• Do not use embedded queries, those things that start with a question mark (?).

The URI should show the structure, and even by removing the last element, you should always be able to get to a resource.

Some people feel the URI should point to a lower-level resource. That is, not a web page or a database but something more specific. I think it all depends on what level in the hierarchy you're at.

REST or SOAP? The Tale of the Tape

So, if there are three possible ways to "style" your web services, what's the best way to go? Which of the three is the best option? And that really is the best way to put this—"the best option"—because the truth is both REST and SOAP (RPC is really a precursor to SOAP, so we'll combine those two, even though RPC is simpler than SOAP) are well-built, mature approaches, and either one can be used. But there are differences, and the better choice depends on you and your situation.

XML vs. JSON

The first difference we'll look at is the form the data can be transferred in.

SOAP is committed to XML, and you must use it to transfer the data. REST can use either XML or JSON.

XML, of course, is known for its size, as in large, and many people prefer the shorter and more efficient JSON. On the other hand, XML can transfer any type of data, whereas JSON has some restrictions. Depending on the type of data you want to transfer, and whether or not you have any bandwidth limitations (although no one ever wants to waste bandwidth), you may decide that you can't afford XML's wastefulness and therefore have to go JSON and therefore REST.

Complexity

REST is simple. In short, it consists of building a URI and then using a standard protocol (generally, but not necessarily, HTTPS) to transfer the data in either XML (bloated) or JSON (not so bloated) format.

SOAP is more complex, having a formal structure associated with it and consisting of four basic parts.

• First, the envelope, which defines the message as a SOAP message and is required
• Second, the header, which is optional and obviously carries the header information
• Third, and also required, the body, meaning the details of what this request is asking for
• Fourth, and optional, the fault, where information about errors and problems is stored 

Obviously, there's a lot more structure and overhead associated with SOAP than with REST and you can look at this in two different ways. You can say that SOAP is more standardized (and that is true) while REST is more freeform. Or you can say that SOAP is more burdened with structures that don't really add anything to the user experience and REST is clean and clear in it's presentation. Up to you.

Statelessness

One of the key questions to ask yourself is what role the state plays in this process. That is, does the server need to know the state of the transaction so that it can return to it at a particular point, or is each request a standalone message?

If you need to keep track at the server (ASYNC processing might be one example of this) of where you are in an application, then you need SOAP. If it doesn't matter, then you can go REST.

Security

Everyone is concerned about security these days and it rears its ugly head here as well.

In terms of transport, it's a draw because both SOAP and REST can use HTTPS and its associated encryption. Beyond that, however, there's something else to consider, something that is somewhat controversial. SOAP supporters say that sending things in an envelope over HTTP or HTTPS is all the security you need. REST advocates counter by pointing out that with a RESTful request, the administrator (the firewall) is able to look at the request without breaking into an envelope and determine based on the HTTP command that's being issued (Get vs. Delete, for example) just how dangerous this request is. You cannot do the same thing as easily on the SOAP side. Essentially, SOAP leaves this sort of security up to the application programmer, while REST uses facilities built into the infrastructure (network, firewall, etc.) to do this policing.

So What Should You Do?

That's the real question, isn't it? Nobody really cares what the differences are; they just want to know which one to use. Because there's always a correct answer, right?

But that's not always the case. And this is one of those cases. Both methods are solid, and both have their advantages, but in a world that was once totally dominated by SOAP, REST is steadily gaining ground.

So take a look at your web apps, or consider this when you build your first: are you RESTful?