REST Architecture
Sweet, more acronyms. I like this one though, since it is only three words for a four letter acronym. Figure that one out. Either way, REST stands for REpresentational State Transfer. What? I know.
Here is how a web application (should) work. You make a request for a resource (such as a web page, an image, etc) and that resource is then delivered to you, the user. Actually, what is delivered is a representation of that resource. Huh? Think of it like this. If you are a human user, you request a collection of articles and what is delivered is a web page that lists out those articles. You were delivered a visual representation of the collection of articles. If you are an application, you might request the same collection of articles, but rather than having a web page returned, you want XML data returned. Again, the application was delivered a representation of the collection of articles. Alright, drilled that one home.
On to the state transfer. When you are browsing a web page, you can click on links to navigate to another web page. These links fire off requests to the web server, which then respond with the proper web page (just what we covered above). The process of clicking a link can be thought of a requesting another state of the application. So let's say that we are looking at our collection of articles again, and we click a link to view an article. What we are doing is asking for another representation of data, and therefor moving the application into another state. That's where the "state transfer" part of the acronym comes in. As we move from one resource to another (one URL to another) we are transferring between application states. Whew, that was complicated, considering that it all seems pretty obvious. Think again.
REST architecture is just a way of building applications. It is not a web standard, or anything like that. Much like DRY (Do not Repeat Yourself), REST is simple a philosophy of how web applications should work. However, to Joe Developer, this should be something to get familiar with, and the why has to do with web services.
Web services are going to be more and more popular as people start to understand the benefits of them. For now, let's stay within the realm of our example. We have our collection of articles, and we want to offer an API to let our partners access our articles and submit their own articles. By offering an API (Application Programming Interface) other developers can build applications that can communicate with our web service and incorporate our articles. Sounds like a lot of work, right? It could be, but here is where REST comes in, and the point I would like to get across. It doesn't have to be that much more work as long as we plan correctly. There, I said it.
There are two things to consider here. The first is how we structure our URLs so that we can provide data to all of our users. For that, and most things REST, we want to rely on the HTTP request method, which will be something like GET, POST, PUT, or DELETE. Most of us are familiar with GET and POST. When we want to make a normal request for data, we use a GET request, which almost every link that we see on web pages uses. When we want to submit data to a form, we use the POST request. This tells the server that there is incoming data. Less used, but with just as much power, are the PUT and DELETE requests. These tell the server a bit more about the context of our request, and also let us clean up our URLs a bit. Lets show an outline:
We want to provide the following functions for our articles API, followed by the URL and request method:
List Articles: (/articles) -GET
Show Article: (/articles/1) -GET
Edit Article: (/articles/1) -PUT
Delete Article: (/articles/1) -DELETE
New Article: (/articles/new) -POST
Seems easy enough. Notice how we use the same URL for showing an article, editing and article, and deleting an article. This is because we can use the request method to determine what it is that we want to do. This means that we have less URLs to maintain, but it also means that requests must be correct. No worries, our API will have documentation explaining how to access our services, so we don't need to worry about that.
We do, however, need to make sure that our website makes the proper requests. This leads us to the second challenge, which is returning the correct "representation", or form of data, to the client that requested it. It may not have been clear until now, but we want to use the same URLs for all clients, whether they are asking for HTML web pages, XML data, or YAML data to be returned. The first thing to do is to go through and ensure that any EDIT requests that you are making to the server are made using the PUT method, and that any requests to delete data are using the DELETE method. This is not a big deal, and helps to clean things up anyway.
The only other bit of information that we need is the type of output that the client wants. We can get this from an HTTP header called "Accepts", which lists out the acceptable content-types that the client will understand. In this case, a request from a browser will ask for HTML, and a request from an application would state "text/xml" in that header, telling us that it wants XML returned. A better way may be to include something in the URL, such as an added variable, that states explicitly what type of content to return. My preference here is to define the output format in the request, so that we might make a request for the collection of articles (/articles) by using the following URLs:
/articles.html
/articles.xml
/articles.yml
As you can see, the application should have no problem deciding on what type of output to render. Additionally, it gives us a rock-solid way of being sure what kind of representation the client wants, without having to rely on things like HTTP headers and such.
In the end, REST is just a philosophy. However, I think that as web services start to take off more, and integration of data between websites becomes the norm, developers would be wise to design their applications around this architecture. That doesn't meant that you have to offer web services, but to make sure that your applications are designed in a way that you can add them easily. Not only that, but REST makes use of the HTTP methods the way that they were intended to be used, which is always nice.
0 Comments
Connect with us