previous standard SOAP requests, REST over HTTP uses HTTP verbs which alot of web clients automatically support caching of. This means when your client requests a resource it can pass a timestamp and hashcode to the webservice, and the web service can process those arguments and instead of resending the data it can instead simply send "304? - drastically reducing the load on the client, server, and persistance layers (depending on your implementation of cache checking). Other less obvious benefits include: Because the servers aren't supposed to maintain state anymore, you can have any number of servers answering any and all requests from clients without having to worry about trading session states back and forth There's less client-side software required because data is transferred in a standard format that's already present in most programming frameworks (HTTP) No dependencies on vendor-dependent encoding or decoding of information (see: DataSet in SOAP), your RESTful service is publishing information in a open-standard format Fully supports CRUD operations without having to hack anything in No resource mapping, the resource the client is asking for is clearly defined by the URI they're making the request on With content-type negotiation between the client and the service, can easily add new content types without having to make any drastic changes This type of service definition lends itself more to resources than reporting however. We wouldn't have something like /Services/Customers/SalesReport, because now we're changing our resource definition to be specific to an operation, breaking the ?constrained set of operations'