Damien Katz

The paper does talk about "constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability." Not as dogma, but as constraints that, if adopted, produce systems with certain characteristics, characteristics that often prove to be desirable.

Another way to look at this: if you know of these constraints and intentionally decide -- for whatever reason -- that they do not apply to the particular situation that you are faced with; then peace be with you. In RFC 2119 terms, these constraints are SHOULDs rather than MUSTs.

"So is POST as RPC RESTful? The practice of roll-your-own POST format is alive and well and successful on the web, and therefore, by definition, RESTful."

I could be wrong, but there still seems to be some confusion. I read Chapter 5 of the dissertation, but I guess "the internet" came up with their own version of REST which contrasts with Fielding's version.

"A RESTful web application requires a different design approach from an RPC application. An RPC application is exposed as one or more network objects, each with an often unique set of functions which can be invoked."

http://en.wikipedia.org/wiki/Representational_State_Transfer

Damien, in your post, you mentioned RPC but the wikipedia entry seems to keep RPC and REST separate.

"A RESTful web application requires a different design approach from an RPC application."

I think we need to coin a new phrase NonRPC-REST

With that being said, I think the NON-RPC-REST approach adds more complexity with little benefit. I think this is what you were mentioning in your earlier post.

I think here is still some confusion, it seems that there are two versions of REST out there. Fielding's original REST. We will call this FieldingREST and NonRPCREST. Damien, I think you described FieldingREST in this entry and NonRPCREST in your earlier blog entry.

For example, in the wikipedia article, they make that distinction.

"A RESTful web application requires a different design approach from an RPC application. An RPC application is exposed as one or more network objects, each with an often unique set of functions which can be invoked."

http://en.wikipedia.org/wiki/Representational_State_Transfer#Uniform_interfaces_in_REST_and_RPC

NonRPCREST is bullsh*t and adds more complexity without much benefit.

Berlin: All dogma is bullsh*t. As long as the argument is of the form of "here is an argument which I made up by taking somebody's position and pushed it to an extreme where it can be viewed as dogma, and therefore it is bullsh*t", you aren't advancing the conversation.

But if you were to apply the constraints specified by REST to, for example, a database that you wanted to expose via HTTP, you find that you would do well by constraining your data to be documents, and then to support a uniform set of methods on those documents, taking care to specify cacheability on responses.

You can call this "adding complexity without much benefit". I, however, would call it CouchDB.

Sam,

I was just pointing out that like Damien said, "What is REST...in practice?". I am more concerned about the terminology and what are the "specific" attributes of a REST application, maybe even specified in some architecture document. If not, then lets quit calling it REST.

"But if you were to apply the constraints specified by REST to, for example, a database that you wanted to expose via HTTP, you find that you would do well by constraining your data to be documents, and then to support a uniform set of methods on those documents, taking care to specify cacheability on responses."

Isn't what you described just a well designed/architected documented-oriented web application? Is that really REST? I don't know CouchDB, but I am assuming that documents are associated with a URL resource:

CouchDB Nouns?
http://example.com/documents/my-couchdb-document

userResource = new Resource('http://example.com/documents/my-couchdb-document')
userResource.delete()

For that type of application, it makes perfectly good sense to fully utilize all aspects of HTTP including the ability to add and delete resources.

As Damien mentioned, the original REST document doesn't describe these details.
"There is nothing about verbs, RPC, POST vs. PUT, idempotency, or posting resources back to the same URI from which they were gotten. I was blasting the dogma around those things but was wrong to call it REST,"

Based on the definitions of REST; it looks like you "aren't" supposed to mix the architecture with RPC. I was concerned that you can't use that type of simple POST RPC logic.

Damien, you gave up too easily. There's a major difference between "the web" and what restafarians are pushing. If REST was "just the web," then why is is brought up in conversations about SOAP and RPC? SOAP and "the web" are not competitors.

What everyone seems to be missing is the difference between services whose clients are user agents and services whose clients are autonomous programs. The web is about the former. SOAP is about the latter.

Trying to apply REST to the latter is where things get questionable. If the payload of a REST service is an application-specific XML format (as most of them are), then REST just doesn't add up.

If your REST service is just a "database" of "documents" as Sam Ruby advocates above, then I think this supports my earlier argument: the more a service looks like a filesystem, the more REST makes sense. The more any of its operations diverge from dumb filesystem operations, the worse of a fit REST is.

Joshua Haberman,

Damien has already answered your question when he wrote :
As long as you are not abstracting HTTP away (and ignoring what HTTP gives you for free), your are probably using it RESTfully.

The entire point of SOAP is to abstract away HTTP (i.e. it's supporters love to point out it is "protocol agnostic") which is the DEFINITION of being not RESTful.

@Joshua: I thought the old and still extremely weak "REST only works for human-driven browsers" argument died years ago. Sigh. I can assure you that that argument is entirely wrong, given that I'm among the many out there successfully developing RESTful systems whose clients are, in your terms, autonomous programs. And none of my services look at all like filesystems.

Have you actually written any RESTful systems of the sort that you claim do not work? Clearly not. Coincidentally my latest blog posting entitled "You Have to Experience It" was written just for people like you, who try to speak authoritatively about things with which they have no actual experience.

Joshua Haberman,

"What everyone seems to be missing is the difference between services whose clients are user agents and services whose clients are autonomous programs. The web is about the former. SOAP is about the latter."

With regard to the Web, you couldn't be more wrong.

@Dare: you assume that these autonomous programs making requests to services are running over HTTP to begin with. Why do you assume this? REST has to do better than competing with SOAP, it's got to compete with RPC-like request/reply systems that are done right. And done right, request/reply services operating over the internet would not run over HTTP. It just doesn't fit.

@Steve: I have never claimed that RESTful systems "do not work" -- to claim so is to fundamentally misunderstand my argument. Anything that transfers bits can be made to do request/reply. I could write a "web service" that accepts requests by email (over SMTP) and puts the reply in the "250 Ok" SMTP server acknowledgement. It would "work", but is it actually a good idea? Specifically, does it buy you anything over the alternative?

Yes, obviously you can design RESTful services whose clients are autonomous programs. Of course you can! But does it offer benefits that are greater than the costs compared to the alternative? (btw, the alternative is not SOAP). This is the argument that REST advocates consistently fail to make IMO.

@Noah: so you are claiming that the Web was not designed primarily for user agents? Of course there are important non-user-agent clients of the web, most notably spiders that crawl the web to build search indexes. But at the end of the day, the web is primarily about serving user-agents. Even RFC2616 says so:

Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin server.

@Joshua: that's another weak argument. I could ask you the same question: can you prove the benefits vs. costs of whatever alternative it is that you're arguing for? But I doubt you'd answer that question, given that you didn't answer my earlier one about whether you've actually written any RESTful systems.

I've published several columns earlier this year and in past years on the benefits of RESTful approaches; all are available under the Internet Computing columns area on my website, and a new one on the same topic will be published in early September. I'm just one of many REST proponents who have produced a number of informative publications about the benefits of REST -- given your comment, you've apparently never bothered reading any of them. What's more, I've worked with RPC-oriented systems for 20 years and REST-oriented systems for 5 years, and I know from significant firsthand experience with both approaches that the RESTful approach leads to systems that are generally easier to build, maintain, and especially extend. I am so sure of that, I even completely gave up a very lucrative career in the RPC-oriented world almost 2 years ago so I could use REST instead, and am very glad I did.

Have you even bothered to read Leonard's and Sam's excellent RESTful Web Services book? Have you bothered to read and study Fielding's thesis? And again, have you actually built any RESTful systems? If not, then why do you feel qualified to judge the effectiveness of REST?

Joshua Haberman,

No, I never claimed that.

I think you're confused about the meaning of term user-agent.

A user-agent is a network client and this makes no distinction between autonomous and non-autonomous operation. I fail to see how such a distinction would be important.

Google's search engine is a RPC (take a look at the URIs produced: plenty of name/values pairs in there) done right, and over HTTP, and fully RESTful.

Google maps was a game changer when first introduced, and was quickly copied. It is based on the notion of tiling the earth, and providing a distinct URI for each tile at each resolution. Such tiles can be served statically and are readily cached.

Neither service looks like a filesystem.

I like Leonard Richardson's dogma free approach to the subject, and that is indicative of the tone and style of our RESTful Web Services book.

@Steve: way back when we first had this argument, I was trying to steer our discussion towards a cost/benefit analysis of REST vs. RPC, but I couldn't get you to commit to an implementation of REST that you felt fairly represented the REST ideal. You criticized Cisco for inventing their own RPC stack, and I asked you what software stack Cisco should have used instead of writing an RPC stack themselves. I asked you this so we could compare apples to apples, and make objective comparisons like:

- how much work is it to write a client or server stack (the part that is not application-specific) that interoperates with each scheme?
- how much work is it to write the application-level code, for both client and server?
- how do you document your service to clients, and how easy is it to write a client that conforms to your service definition?
- how much help can the service stack give you when you make a mistake? are the error messages helpful? do you get static type checks in static languages? can you verify a priori on the client side whether your request is valid before you send it?

I wanted to have this cost/benefit analysis, Steve, but I couldn't get you to "endorse" anything more specific than "RESTful HTTP services." This may seem crazy, but I don't actually want to spend my life arguing about different ways that computers can communicate. I'd rather make a comparison, get to the bottom of it by identifying the objective trade-offs, and then get on with doing productive things. But if one of the things I'm trying to compare is an amorphous ideal that can take many forms as opposed to a specific implementation, then you have a comparison that no one can ever get to the bottom of. And I'll continue to waste time getting drawn into arguments about REST that will never come to a concrete conclusion.

The articles of yours that I've read are similarly amorphous to me. They speak in generalities. I haven't read an article where you sit down and write the same service using both REST and RPC and compare the two. When you speak in generalities, we can't objectively evaluate any of the specific trade-offs between approaches (like the ones I listed above). Arguments that happen at too abstract a level can't go anywhere, because our positions aren't specific enough for anyone to evaluate anybody else's claims.

No, I haven't written a RESTful service. I've also never written a web service that communicates over SMTP, I've never written a web service in assembly language, and I've never written a web service that encodes its payload into the cells of an excel spreadsheet. And yet I feel qualified to engage in critical discussion about these things. Why is this? It's because we're engineers, not alchemists or mystics. The work we do can be objectively analyzed and evaluated. Doing our jobs requires that we are able to evaluate the costs and benefits of things we have never done. If I asked you why you haven't written a web service in assembly language (and I hope you haven't), you would probably give me very good reasons why it doesn't make sense. And yet you've never done it. What if I tell you "you have to experience it" to understand its benefits? Will you really waste weeks of your life trying it?

@Sam: I do appreciate your dogma free approach. A friend whose opinion I value very highly recommends your book. Said friend also mentioned the Google tile service as an example of a successful RESTful service, and after thinking about it I conceded that in addition to filesystem-like services, I could clearly see the benefits of RESTful HTTP for a service that consists of demand-generated media like images or sounds. Another good example of this is the Google chart API. Both examples make perfect sense to me as a good application of RESTful HTTP.

RESTful HTTP makes sense to me when your service is mostly just transferring opaque, atomic files.

Anyway, I've spent too much time on this thread already -- this is my final word.

@Steve: As a side note, another thing that would help make the discussion more concrete is if you pointed to specific examples of RESTful services that you think fairly represent the REST ideal. For example, you'll notice that I conceded to Sam that services like the Google tile service and the Google chart service do make sense when written RESTfully.

On the other hand, I would point to the Flickr API as an example of a service that does not cater well to REST (and I think you would agree that what they call their "REST" option isn't really RESTful). So for you or any REST advocate who thinks that a RESTful approach is always superior to an RPC one, I would like to see how you would model the existing operations of the Flickr API to a RESTful interface.

The whole API is rather big, so I'll pick one method in particular: flickr.photos.getCounts. Given a list of dates, it returns a histogram of the number of photos taken for each date range for the authenticated user. How should this be made RESTful? What is the resource?

@Joshua: your arguments are going from weak to ridiculous. What benefits would one gain from trying to perform the various contrived examples you've come up with, such as writing a web service in assembly language?

The reason I push on the experience side of the equation is because I know how hard it is to get over all the assumptions and baggage that those coming from RPC-land bring with them. After all, I made that journey myself, and I know firsthand just how many hidden assumptions one can make about this stuff. I can give you a lot of information about the approaches, but ultimately I can't fix or undo all those assumptions for you; that's something you have to do for yourself. I also have no details regarding what language(s) you use, what you work on, etc. so it's pointless to ask me to come up with specific examples relevant to your work and experience.

I'm sorry you find my columns "amorphous," but writing very detailed examples in the columns would take up more space than I'm allowed and more importantly would fail to get the important general points across appropriately. Either way, I wouldn't think it would be that difficult for you to apply the general points in those columns to your particular tasks. I mean, as you say, we're engineers, right? We're supposed to be able to move up and down the spectrum between specifics and abstractions as necessary and appropriate.

Why would I bother writing the same service both ways? I already know which approach I'd choose, based on all the years of experience I already described. If you think having a service built both ways will help you learn, then go do it for yourself -- that way you'll not only get the info you want, but you'll gain a much better appreciation for developing RESTful systems, i.e., experience. If I did it for you, I'd be wasting my own time and you'd be learning nothing.

At the end of the day I couldn't care less whether you use REST or not. If you choose not to use it, then that's your choice, no big deal. But just make sure you don't go around writing inaccurate or incorrect information about REST as you've done here, especially given that you've never used it, as we'll definitely call you on it every single time.

Damien, I think you are wrong when you say that REST is just the web. If you read Roy's thesis more carefully you'd see that it is an architectural style which was defined to fit for the architectural needs of the web.
There's no mention of verbs etc. since HTTP is a technology not an architecture.
REST over HTTP (which is the common implementation) is just one option to implement this style. Also you can build system that utilize REST along with other architectural styles (just as REST itself was derived from multiple styles) - for instance our system utilizes both REST and EDA (event driven architecture)
The benefit from using REST over HTTP ubiquity of the standard which help REST live up to the promised integration ease across enterprises

Arnon

REST is simply a description of the web as it actually work as a distributed hypermedia browser platform.

This is false. REST is a description of the architectural style that informed the design of HTTP 1.1. The fact that applications that do not leverage this architectural style can be given a web page interface is irrelevant.

The practice of roll-your-own POST format is alive and well and successful on the web, and therefore, by definition, RESTful.

From Fielding's thesis:

REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. ... REST concentrates all of the control state into the representations received in response to interactions. The goal is to improve server scalability by eliminating any need for the server to maintain an awareness of the client state beyond the current request. An application's state is therefore defined by its pending requests, the topology of connected components (some of which may be filtering buffered data), the active requests on those connectors, the data flow of representations in response to those requests, and the processing of those representations as they are received by the user agent.

This describes very few applications on "the web." Nearly all of them have some private session state that is unreachable via the web.

What distinguishes HTTP from RPC isn't the syntax. It isn't even the different characteristics gained from using a stream as a parameter, though that helps to explain why existing RPC mechanisms were not usable for the Web. What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services. The result is an application that allows for layers of transformation and indirection that are independent of the information origin, which is very useful for an Internet-scale, multi-organization, anarchically scalable information system. RPC mechanisms, in contrast, are defined in terms of language APIs, not network-based applications.

The "generic interface" in the above passage refers to a restricted set of verbs defined to operate on resources.