下面的文章介紹的比較詳細：
來源：http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci823342,00.html
REST could burst SOAP‘s bubble
Simple Object Access Protocol (SOAP), today‘s de facto Web services communications protocol, and has come a long way since Microsoft first developed it in 1999. However, the latest Web services fad is an architecture called REST, or representational state transfer. First coined in a popular dissertation by eBuilt‘s Roy Fielding, REST is a distributed computing framework that stresses component interaction and scalability. SearchWebServices spoke with Roy Hoobler, director of Internet technologies for Net@Work Inc., about REST and its potential impact on Web services.
Is there a simple way to explain REST?
Hoobler: 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 it really that simple?
Hoobler: 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.
So is REST more of a methodology than a specification?
Hoobler: 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.
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?
Hoobler: 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.
If it‘s so simple, why hasn‘t it caught on like SOAP has?
Hoobler: 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.
Can you give me an example?
Hoobler: 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 easy or difficult is it to learn to work with REST, versus working with SOAP?
Hoobler: 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.
How can a company determine if it should be working with REST instead of SOAP?
Hoobler: 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.
