Representational State Transfer (REST) as Described in a News Presentation
Anchor #1: Good evening, and here is the news. We are simulcasting on radio station WSDL.
Anchor #2: And tonight on the program, a special presentation on Representational State Transfer, also known as REST.
Anchor #1: We'll also be talking a little bit about Simple Object Access Protocol, or SOAP, because the comparison does help to illustrate the core principles of REST.
Anchor #2: But just a little on SOAP, because tonight we're focusing on REST. So let's start off with where it came from. REST was developed in parallel with HTTP, and in fact the World Wide Web is the canonical example of a RESTful system.
Anchor #1: One of the authors of the HTTP specification was Roy Fielding, and he was the first to use the term REST in his doctoral dissertation in 2000.
Anchor #2: Let's start by describing what it is. REST is an architectural style. More specifically, it's client/server, stateless, cacheable, and it stipulates a uniform interface. It's also layered.
Anchor #1: There are a few things it's not, and it's important to understand that. It is not an API or a library, it's not a specification and it's not a protocol. This is one difference between REST and SOAP - REST is a software architecture, and SOAP is a protocol specification.
Anchor #2: Great point, Anchor #1. Let's start at the beginning. A RESTful system is composed of a set of things - nouns. And REST says that there should be a uniform interface to interact with those things - standard verbs.
Anchor #1: The four most important standard verbs are GET, POST, PUT, and DELETE. When you access a resource on the Internet by typing in a URL, it GETs a representation of that resource.
Anchor #2: REST also has the constraint that it is a client server architecture. Pretty self-explanatory, wouldn't you say, Anchor #1?
Anchor #1: Definitely. But even though our audience will know what client server is, we should explain why it's chosen for REST. It improves the portability by separation of duties - the user interface concerns are separated from the data storage concerns.
Now it is time for the weather report. Weather Reporter.
Weather Reporter: Thanks guys. And, you had to know this was coming - clouds!
You see, another constraint of REST is that it is a stateless architecture, and that makes it work well for cloud services. Being stateless means that a session between the client and the storage cloud is not required. This is important because the Internet is comparatively slow, and the response time can vary quite considerably. So, you may not be able to ask a follow-up question in a timely manner.
Anchor #2: Some of the services using REST include Amazon and eBay, isn't that right, Weather Reporter?
Weather Reporter: Exactly.
Anchor #1: Don't forget they also use SOAP, guys. But, Amazon has said in the past that REST accounts for as much as 85% of its services.
Anchor #2: Thanks Weather Reporter. The next constraint of REST is that it's cacheable. Because clients are able to cache results, a response has to somehow indicate whether it can be cached.
Anchor #1: Fielding wrote in his dissertation that this could improve efficiency, scalability, and performance. Those characteristics are the most frequently cited advantages of REST over SOAP.
Weather Reporter: By the way, you've talked a bit about the state transfer part of REST, but it's helpful to know how Fielding defined a representation. This is in section 5.2.1.2 of his dissertation.
Fielding called a representation a sequence of bytes, plus representation metadata to describe those bytes. A parallel might be to consider a text document that can be represented as a plain text file, a Microsoft Word document, or a PDF.
Anchor #2: We talked earlier about the uniform interface constraint. Fielding described this as the central feature that sets REST apart from other network-based styles.
Anchor #1: It definitely is different from SOAP. We will have to come back to it. But there are still two more constraints we haven't mentioned yet, Anchor #2.
Anchor #2: Right. We've been going in the order that Fielding presented them in his dissertation, and the first several constraints are probably the most important. The next constraint you're thinking of, Anchor #1, is that it's layered.
Anchor #1: The layering helps keep it simple, compared to SOAP. That's another of the most common comparisons between REST and SOAP. REST is very simple, and easy to read for an end-user.
Anchor #2: Whereas SOAP can be much more complex, and it has a bigger payload associated with it.
Anchor #1: The last constraint is one that often gets left out of discussions about REST. That one is the code-on-demand constraint.
Anchor #2: That's right. Fielding described this final constraint as an oxymoron because it's optional.
Anchor #1: An optional constraint is a bit weird, you have to admit.
Anchor #2: It is, but Fielding explains why it's done this way. Basically, it allows for a system composed of disparate clients. And it does allow the clients to be smaller. Rather than trying to build a client to do everything, developers can build a smaller client and then the system can be extended by downloading applets.
Anchor #1: That's all the constraints, Anchor #2. Let's get back to the uniform interface constraint for a moment.
Anchor #2: This constraint helps to simplify the system architecture and improves visibility of interactions.
Anchor #1: That visibility is another perceived advantage of REST, by the way.
Anchor #2: It is. Anchor #1, you mentioned earlier there are several standard verbs, like GET and POST. GET is a significant verb.
Anchor #1: It's a good way to illustrate how RESTful systems work. You have a domain, and resources within that domain. For instance, you might have www.ford.com/cars . You can then GET a representation of a particular car. Say, www.ford.com/cars/focus.
Anchor #2: Great example, Anchor #1. Because it's RESTful, I can open up my browser and just type in that whole address, www.ford.com/cars/focus, and always go to the home page for the Focus. That means it's very convenient to bookmark.
Anchor #1: It's a representational state transfer. So if you open up your browser and type in that address for the Focus, the resource you get back has what you need to go deeper into the features of the Ford Focus, by clicking on hyperlinks.
Anchor #2: And it's easy to read. It doesn't take a developer to figure out that I can open up my browser and type in www.ford.com/trucks/f150.
Anchor #1: The non-RESTful approach might be something like www.ford.com/App/ViewVehicleSearchResults?retrieveParameters=true&category=trucks&model=f150 .
Anchor #2: That's a mouthful. It does show a couple of key points. Firstly, it is verb based, not noun based - ViewVehicleSearchResults. And secondly, it embeds the parameters in the query string.
Anchor #1: There are clearly a few advantages to REST, and a big one is its simplicity. That helps with the scalability, and one reason is because it supports a heterogeneous architecture. You can be accessing a web page on a Sun station, a UNIX box, or a Windows server, and not even know.
Anchor #2: The uniform interface is simple, so there aren't a lot of requirements for a client. All of this makes it sound like REST is a knockout over SOAP, and as we saw with Weather Reporter's Amazon cloud it's certainly got a lot of traction.
Anchor #1: But there are still instances where SOAP wins out. REST is simple, which is its appeal, but that means that SOAP can better support some types of advanced functionality.
Anchor #2: And it's also possible to specify a very formal interface in situations where that may be required. As you point out, Anchor #1, SOAP can address complex nonfunctional requirements that a RESTful developer would need to build for herself.
Anchor #1: Well, that's about all we have time to cover tonight. Weather Reporter, any predictions on weather for this weekend?
Weather Reporter: The Oracle says -- limited Sun. Sorry guys.
Everyone: Goodnight!
References:
Anchor #2: And tonight on the program, a special presentation on Representational State Transfer, also known as REST.
Anchor #1: We'll also be talking a little bit about Simple Object Access Protocol, or SOAP, because the comparison does help to illustrate the core principles of REST.
Anchor #2: But just a little on SOAP, because tonight we're focusing on REST. So let's start off with where it came from. REST was developed in parallel with HTTP, and in fact the World Wide Web is the canonical example of a RESTful system.
Anchor #1: One of the authors of the HTTP specification was Roy Fielding, and he was the first to use the term REST in his doctoral dissertation in 2000.
Anchor #2: Let's start by describing what it is. REST is an architectural style. More specifically, it's client/server, stateless, cacheable, and it stipulates a uniform interface. It's also layered.
Anchor #1: There are a few things it's not, and it's important to understand that. It is not an API or a library, it's not a specification and it's not a protocol. This is one difference between REST and SOAP - REST is a software architecture, and SOAP is a protocol specification.
Anchor #2: Great point, Anchor #1. Let's start at the beginning. A RESTful system is composed of a set of things - nouns. And REST says that there should be a uniform interface to interact with those things - standard verbs.
Anchor #1: The four most important standard verbs are GET, POST, PUT, and DELETE. When you access a resource on the Internet by typing in a URL, it GETs a representation of that resource.
Anchor #2: REST also has the constraint that it is a client server architecture. Pretty self-explanatory, wouldn't you say, Anchor #1?
Anchor #1: Definitely. But even though our audience will know what client server is, we should explain why it's chosen for REST. It improves the portability by separation of duties - the user interface concerns are separated from the data storage concerns.
Now it is time for the weather report. Weather Reporter.
Weather Reporter: Thanks guys. And, you had to know this was coming - clouds!
You see, another constraint of REST is that it is a stateless architecture, and that makes it work well for cloud services. Being stateless means that a session between the client and the storage cloud is not required. This is important because the Internet is comparatively slow, and the response time can vary quite considerably. So, you may not be able to ask a follow-up question in a timely manner.
Anchor #2: Some of the services using REST include Amazon and eBay, isn't that right, Weather Reporter?
Weather Reporter: Exactly.
Anchor #1: Don't forget they also use SOAP, guys. But, Amazon has said in the past that REST accounts for as much as 85% of its services.
Anchor #2: Thanks Weather Reporter. The next constraint of REST is that it's cacheable. Because clients are able to cache results, a response has to somehow indicate whether it can be cached.
Anchor #1: Fielding wrote in his dissertation that this could improve efficiency, scalability, and performance. Those characteristics are the most frequently cited advantages of REST over SOAP.
Weather Reporter: By the way, you've talked a bit about the state transfer part of REST, but it's helpful to know how Fielding defined a representation. This is in section 5.2.1.2 of his dissertation.
Fielding called a representation a sequence of bytes, plus representation metadata to describe those bytes. A parallel might be to consider a text document that can be represented as a plain text file, a Microsoft Word document, or a PDF.
Anchor #2: We talked earlier about the uniform interface constraint. Fielding described this as the central feature that sets REST apart from other network-based styles.
Anchor #1: It definitely is different from SOAP. We will have to come back to it. But there are still two more constraints we haven't mentioned yet, Anchor #2.
Anchor #2: Right. We've been going in the order that Fielding presented them in his dissertation, and the first several constraints are probably the most important. The next constraint you're thinking of, Anchor #1, is that it's layered.
Anchor #1: The layering helps keep it simple, compared to SOAP. That's another of the most common comparisons between REST and SOAP. REST is very simple, and easy to read for an end-user.
Anchor #2: Whereas SOAP can be much more complex, and it has a bigger payload associated with it.
Anchor #1: The last constraint is one that often gets left out of discussions about REST. That one is the code-on-demand constraint.
Anchor #2: That's right. Fielding described this final constraint as an oxymoron because it's optional.
Anchor #1: An optional constraint is a bit weird, you have to admit.
Anchor #2: It is, but Fielding explains why it's done this way. Basically, it allows for a system composed of disparate clients. And it does allow the clients to be smaller. Rather than trying to build a client to do everything, developers can build a smaller client and then the system can be extended by downloading applets.
Anchor #1: That's all the constraints, Anchor #2. Let's get back to the uniform interface constraint for a moment.
Anchor #2: This constraint helps to simplify the system architecture and improves visibility of interactions.
Anchor #1: That visibility is another perceived advantage of REST, by the way.
Anchor #2: It is. Anchor #1, you mentioned earlier there are several standard verbs, like GET and POST. GET is a significant verb.
Anchor #1: It's a good way to illustrate how RESTful systems work. You have a domain, and resources within that domain. For instance, you might have www.ford.com/cars . You can then GET a representation of a particular car. Say, www.ford.com/cars/focus.
Anchor #2: Great example, Anchor #1. Because it's RESTful, I can open up my browser and just type in that whole address, www.ford.com/cars/focus, and always go to the home page for the Focus. That means it's very convenient to bookmark.
Anchor #1: It's a representational state transfer. So if you open up your browser and type in that address for the Focus, the resource you get back has what you need to go deeper into the features of the Ford Focus, by clicking on hyperlinks.
Anchor #2: And it's easy to read. It doesn't take a developer to figure out that I can open up my browser and type in www.ford.com/trucks/f150.
Anchor #1: The non-RESTful approach might be something like www.ford.com/App/ViewVehicleSearchResults?retrieveParameters=true&category=trucks&model=f150 .
Anchor #2: That's a mouthful. It does show a couple of key points. Firstly, it is verb based, not noun based - ViewVehicleSearchResults. And secondly, it embeds the parameters in the query string.
Anchor #1: There are clearly a few advantages to REST, and a big one is its simplicity. That helps with the scalability, and one reason is because it supports a heterogeneous architecture. You can be accessing a web page on a Sun station, a UNIX box, or a Windows server, and not even know.
Anchor #2: The uniform interface is simple, so there aren't a lot of requirements for a client. All of this makes it sound like REST is a knockout over SOAP, and as we saw with Weather Reporter's Amazon cloud it's certainly got a lot of traction.
Anchor #1: But there are still instances where SOAP wins out. REST is simple, which is its appeal, but that means that SOAP can better support some types of advanced functionality.
Anchor #2: And it's also possible to specify a very formal interface in situations where that may be required. As you point out, Anchor #1, SOAP can address complex nonfunctional requirements that a RESTful developer would need to build for herself.
Anchor #1: Well, that's about all we have time to cover tonight. Weather Reporter, any predictions on weather for this weekend?
Weather Reporter: The Oracle says -- limited Sun. Sorry guys.
Everyone: Goodnight!
References:
Fielding, R. (2000). In Taylor R. (Ed.), Architectural styles and the design of network-based software architectures. United States -- California: University of California, Irvine. Retrieved from http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
O'Neil, J. (Producer). (2009). REST. [Web]. Retrieved from http://channel9.msdn.com/Blogs/dpeeast/Northeast-Roadshow-REST
Lesem, S. (2009, November 17). Understanding cloud storage APIs: standards, functions, lock-in, and what's next. Retrieved from http://cloudstoragestrategy.com/2009/11/understanding-cloud-storage-apis.html
Chappell, D. (2009, March). SOAP vs REST: complementary or competitive? Retrieved from http://proceedings.esri.com/library/userconf/devsummit09/papers/keynote_chappell.pdf
O'Reilly, T. (2003, April 3). REST vs. SOAP at Amazon. Retrieved from http://www.oreillynet.com/pub/wlg/3005
Published by Ian Mundell
Ian Mundell grew up in New Zealand and spent a lot of time engaging in typical kiwi activities, such as hiking, camping, kayaking, and sailing. He spent three years at the University of Auckland, New Zealand... View profile
- Newspaper and TV News Weather Proclamations of "Record Rain Fall" and "Record Temp...Unbeknown to the casual reader or televsion news watcher those Records Temperatures and Record Rain Fall Numbers are Pure deception.
What to Do when Airlines Cancel Flights Due to Bad WeatherAre you aware of your airline's flight cancellation policy? You might be surprised to learn that many airlines don't post them on their web sites. When your flight gets canceled...
Balloon Boy Hoax ?- Falcon Heene Tells Reporter He Did This as Part of t...Balloon boy, Falcon Heene said he did this because "you guys said it was part of the show". He said this during a live interview last night. His father, Richard Heene, quickly c...
Broadcast Reporter Package Ideas for Campus JournalistsIf you're a Broadcast Journalism student struggling to find a story to cover for your field reporting packages, check out these suggestions & tips.- Winter Weather in Atlanta: Snow Cools HotlantaSnow rarely comes to Atlanta and, when it does, it usually comes in flurries. As of the filing of this report, 47 counties in northern Georgia were under storm warnings, watches and advistories.
- Weather Reporting Lesson Plans
- Enoch Pratt Free Library: Southeast Anchor Branch
- Rigging a Sea Kayak with Stabilizing Sponsons and an Anchor
- Central North Dakota Weather: Snowfall Expected to Reach Five Feet
- A Mall Without a Strong Anchor and a Mall Without Tenants
- Huge Fireball Accompanies Weather-Related Florida Accident that Kills Two
- Weathering TV Weather