SearchSOA: Is there a simple way to explain REST?
Here's the way Amazon.com is using REST. Typically, if I'm building an XML application, usually I have to have the XML file on my machine. However, with most XML apps, that doesn't have to be the case because you can access the XML file through any valid URL. For instance, I can go out to your Web site and get an XML file and parse it on my machine.
If it's in a database, it has to be a local database. I can't connect directly to Amazon's database, and there's no way they're going to let me. So, they might have a SOAP service, or they might do a query through HTTP, which is what they're doing. What they're doing (with REST) is building an XML document on the fly and returning (database data) via HTTP. I can use that on my system, save it and process it. There's a lot I can do with that and I don't need SOAP, and I don't have to program anything.
Is REST more of a methodology than a specification?
The REST controversy
Roy Fielding, who coined the term REST, believes there's too much hype surrounding REST. In a posting at W3C.org, he wrote that it is an architecture and can't be compared to SOAP, which is an implementation standard. Read more:
Fielding's W3C posting
It's a technique. Other sites that have used this are a lot of the blogger sites, Web log sites and such. They offer the same thing, but they use a method called RSS (Resource Site Summary). They offer almost the exact same thing but it's in RDF (Resource Developer Framework), which is an XML format. For instance, if I have a list of the links on my Web site to tell you about, all I have to do is give you a URL were you can download the info in RDF. So it's similar to REST and what Amazon's doing. It's like a very cheap subscription service. You wouldn't have to write a Web service. You can just go there and get the content.
Is it really that simple?
It's a very simple process. If someone has an XML file and they give me the URL for it, then I can download the content. There's almost no programming involved. Someone can upload a text file that's basically XML, and I can download it through the browser. It's a little more complicated than that, but not much.
SOAP is also rather slow compared to REST, because of the communication that's going on. When you're using REST, you're pulling that info just as if you were looking at a Web page on the site. It comes down really fast. With SOAP, there's a lot more transactional information moving behind the scenes.
If it's so simple, why hasn't it caught on like SOAP has?
It's not as powerful. With REST, you're just grabbing content. There's not as much processing that needs to be done. You can do much more complex operations with SOAP. If Amazon needed to send me much more information, and then I wanted to process that info -- like in some bank transaction where I had to give them a lot of info -- and then they had to check it and continue the transaction a little bit longer, that's where SOAP is very good. REST has not taken off in the business world because [the] people actually building these big integration servers [think] it's not powerful enough and doesn?t do enough. Amazon.com is currently using a REST-style Web service to share product-pricing info with its reseller partners.
What would it have to do if it used SOAP to do the same thing?
First, Amazon.com would have to implement a SOAP server. They'd have to build that themselves, which can be complicated, or they could use a third party system. Once they have a SOAP server, end-users would have to build SOAP clients that can communicate with the SOAP server. There would be a lot of programming involved, and most people haven't used SOAP yet, so they'd be left out. With technologies like REST or RSS, that kind of programming doesn't have to take place, and Web services don't take as much effort.
How easy or difficult is it to learn to work with REST, versus working with SOAP?
More resources on REST and SOAP
To work with SOAP, you really need some kind of infrastructure -- like from IBM or Microsoft -- that supports SOAP. Some third parties, like Cape Clear, offer SOAP implementations, but you have to have all that software installed and know that infrastructure. With REST, to display that information on a Web page, you have to know XML and XSLT, and a lot of platforms -- like WebSphere and all of those Java application servers -- have that built in, or it's very easy to add it on.
Going the other way, if you wanted to use SOAP, you'd have to use the whole .NET framework, or you'd have to use WebSphere Studio. You'd have to use a hefty application, so it's an investment of time and money.
Can you give me an example?
If I'm using REST, I might be able to get a Web site's list of stock tickers, but I can't get the values of those tickers. If I'm using SOAP, I can get to the values, manipulate them, and then send the results of my calculations. Let's say I got the values from you, and I wanted to let you know that they're wrong. If I wanted to send you back something that says they're wrong, with REST that can't be done. With REST, you request information, you get it, and that's where it ends.
How can a company determine if it should be working with REST instead of SOAP?
I would say if a company's just working with content-oriented data, and you have not implemented SOAP, then REST is a very good way to start working with XML and start displaying syndicated content. If you've implemented SOAP and the infrastructure is in place and you've got programmers coming out your ears, then you don't need to use REST.