关于REST

REpresentational State Transfer（REST） 代表性状态传输
REST是WEB服务的一种架构，简单的说就是通过HTTP协议提供XML数据。最常见的应用就是RSS.
REST的基本规则：
1、所有可区分的实体都是资源，这些资源可以是一个XML文档，或者是一个HTML页面来进行描述（Representation ）. 补充：鉴于xml的结构化，跨平台等等特性，建议所有的资源都通过xml进行描述
2、每个资源通过一个唯一的URL进行定义
3、WEB服务返回的数据应该包含其它数据的链接地址（URL）. 也就是说，把要提供的数据设计成一个信息网络
4、服务提供方维护一组资源，并公开一组基本操作来执行以下任务：
检索资源（HTTP GET）
创建新资源 （HTTP POST）
修改资源 （HTTP POST）
删除资源 （HTTP POST）


REST与SOAP（Simple Object Access Protocal, 简单对象访问协议）的比较
1、从基本原理层次上来讲，REST适合于面向资源的服务，服务提供方维护一组资源，并公开一组基本操作来执行以下任务：

检索资源

修改资源

创建新资源

删除资源

资源是他们关心的中心。

而SOAP更适合于面向活动的服务，客户端请求的每个活动的操作是他们关心的中心。

2、从使用上来说，REST更简单，更快速，而SOAP在安全性方面会有更多更好的方案供选择

Flickr就是采用REST方式提供的 WEB SERVICES


而Amazon95％的服务也采用该方式

了解更多的WEB服务和SOAP 到http://www-128.ibm.com/developerworks/cn/webservices/


下面的文章介绍的比较详细：

来源：

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.