mnot’s blog

Design depends largely on constraints.” — Charles Eames

Monday, 20 March 2006

Don’s False Choice

True to form, Don’s using his witty charm and good looks (such as they are ;) to shape discussion of a topic… in this case, REST, where he splits the RESTifarian world into two; “hi” and “lo.”

To get a more accurate picture of what we’ve done so far, I’ll break this category in two: Lo-Rest, which is the use of HTTP GET (or equiv) for information retrieval/query, and Hi-Rest, which is characterized by the use of HTTP PUT and DELETE (or equiv) for doing update.

This is a false choice, because REST is not about GET, PUT, POST and DELETE as such. It’s about using uniform verbs to gain transparency, using hypermedia as the engine of application state, and leveraging the deployed standards and infrastructure. The HTTP methods are just the uniform verbs in one RESTful protocol.

Still, it’s understandable, because there’s been a lot more heat than light about REST, and some of the cargo culters have decided “POST bad, PUT good.” In truth, it’s not at all black and white. REST is not a set of unbreakable rules, it just gives you properties that you can choose to use — or elect not to — based on your application’s needs. It requires the designer to be intelligent (in the good science way), not a set of magic tools or unbreakable rules.

Don has effectively made the observation that a lot of other people (especially of the Web services sort) have made; while the benefits of GET’s transparency are obvious, they’re less apparent for PUT and DELETE, so why not just take the easy (lo) road and use POST?

I think there are two answers; 1) hopefully, we’ll have some concrete benefits for that transparency some day (think offline), and 2) thinking in terms of GET/PUT/DELETE first — using POST only as an escape hatch — leads you down a path where your application will be using transparent methods a lot more than opaque POSTs.

In the meantime, I don’t see much benefit to dividing the REST world into “hi” and “lo.”


Filed under: Web Web Services

9 Comments

Mark Baker said:

Big +1.

I don't know who the cargo culters are though (re "POST bad, PUT good"). But I'd say to them, if you need to PUT, PUT, but if you need to POST, POST. It's no different than if you had a Web service offering getWeatherReport() and getStockQuote() operations; if a client wanted weather reports, guess which one they'd have to invoke?

Monday, March 20 2006 at 1:36 PM +10:00

Bill de hora said:

"if you need to PUT, PUT, but if you need to POST, POST."


Not being able to assume PUT/DELETE *sucks*. I find POST low-level and unspecific compared to PUT/DELETE.


Thankfully HTTP didn't ship with GRUNT :)

Monday, March 20 2006 at 6:38 PM +10:00

Ryan Tomayko said:

I'll play whipping boy since I came out somewhat in support for Don's post (or, I came out in support for the lo/high terminology at least).

The term "lo-REST" could, with luck and some work, accurately describe the subset of REST that's proven itself at web scale in practice. That is not to say that there's a choice to be made, only that we've identified a subset of the larger architecture that's been weighed and found adequate for a specific case (the web circa 2006).

There seem to be two arguments against this kind of subsetting. First, that it presents the appearance of two separate architectures/choices, which I would agree is wrong and is not how I'd envision the term being used. i.e. I wouldn't say, "should we go with lo-REST or high-REST for project XXX?" I'd say something more along the lines of, "HTML forms follow lo-REST, a mistake duplicated by XForms," and "most AJAX libraries have full high-REST capabilities". (The more I think about it the more high-REST seems silly, I'd just say "REST").

The second argument against recognizing a subset seems to be that although a majority of the web follows only a portion of REST architecture, that it's enough to validate the entire architecture. i.e. GET/POST, URLs, and media-types as they are commonly used today provide enough supporting evidence for the viability of uniform interface and hypermedia as an overall architecture that we can assume that what is now being called "high-REST" will work as well in practice as "lo-REST" if we can just convince people to use it properly. My heart is certainly here but my mind refuses to listen. And this argument seems to bring even more value to defining a lo-REST subset because it means we can talk about the benefits of high-REST in a way that clearly distinguishes them from the limited subset used today.

After writing this, I'm kind of not liking how the terms flow in use. I have a hard time fitting them into sentences in a way that makes sense. That being said, I still frequently find myself wanting to separate the portions of REST architecture we see everywhere from the portions we're trying to forward.

Tuesday, March 21 2006 at 5:09 AM +10:00

Mark Nottingham said:

Ryan,

Fair enough. My concern is that even with the best intentions, people will still tend to use the terms in terms of choices; it's just human nature.

This is especially true now that REST is getting momentum; one of the most interesting aspects of Don's post to me was the implication that Microsoft is getting enough customer interest in REST to justify thinking and talking about it, even from the Web services folks.

Tuesday, March 21 2006 at 6:40 AM +10:00

Dimitri Glazkov said:

Ryan,

Are you sure you're talking about subset of REST and not just HTTP protocol? If anything, we should be saying lo-HTTP and hi-HTTP (or full HTTP).

I think this the phrase "a subset of the larger architecture" needs clarification. Let's remove HTTP and its verbs from the picture and clearly depict what exactly this subset is.

Roy brings REST together as derivation of (following 5.1.* points) Stateless, Cached, Uniform, Layered, Code-on-Demand architectural styles. Which ones do we drop or mutate to create the aforementioned subset? What's added?

Without this exercize, it sure looks like you guys are just mistaking HTTP and supporting architectures from the actual proposition made back in 2000.

And while I do care about Microsoft coming around to liking REST, I also want 'softies to "get it", not build an MS-REST frankenstein.

Thursday, March 23 2006 at 11:28 AM +10:00

Mark Nottingham said:

Dimitri,

It's true that REST is independent of HTTP. However, HTTP is by far the most widely deployed RESTful system, and any use of REST IMO has to be compatible with HTTP to offer any value.

So, many people are really talking about HTTP when they talk about RESTful systems, and I think that's OK; it's more grounded in real-world discussions (not that the abstraction in Roy's thesis is bad, it's just difficult to apply as-is).

WRT MSFT, I totally agree. Although I frankly don't care if they don't get it, they've got enough already.

Thursday, March 23 2006 at 12:09 PM +10:00

Ryan Tomayko said:

More discussion over here:

http://blog.jonnay.net/archives/669-Kicking-the-RESTafarian-beehive...-the-score-thus-far.html#comments

"REST" mean two things right now, I think:

1. The architecural style described by Fielding.

2. The ongoing consideration of the architecural style described by Fielding as related to common practice on the web and its core protocols and formats.

In #1, Fielding puts constraints on the web. In #2, the web puts contraints on Fielding. Godel would be proud.

Thursday, March 23 2006 at 2:40 PM +10:00

Sandeep Shetty said:

http://sandeep.shetty.in/2006/04/browserland-http.html

All this talk about Lo-REST and Hi-REST is so misleading.

There arent two types or levels of REST. There are just Components that support HTTP to various degrees and that is where the problem lies.

Saturday, April 1 2006 at 3:38 PM +10:00

Stefan Eissing said:

On the first day He made GET. On the second PUT. On the third DELETE. Then came a flurry of TRACE, HEAD and OPTIONS on day four and five.

Since the week was almost over and he had promised the kids a day off, He made POST so that someone else could continue the work.

On the seventh day He had rest and lots of fun with the kids.

Sunday, April 2 2006 at 2:27 AM +10:00

Creative Commons