[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ProgSoc] REST vs. HTTP in the real world



On Thu, 31 May 2007, Nigel Sheridan-Smith wrote:
> John Elliot wrote:
> > I'm done. I've poured hours into this discussion now, and I really
> > don't have anything additional to contribute. I've made my points
> > about PUT and DELETE, and I've made sense to some people. I'm happy
> > about that.
>
> What was the point, John? I think you already had the outcome in
> mind

Of course I did. That was basically to make a number of points, for the 
sake of having them heard. I benefit, because it's an opportunity to 
clarify my thinking.

> complete with abuse for people with alternative viewpoints... 

Why do people say that I'm abusive. I don't get it.

I mean, really. I don't.

Show where I was "abusive", and I'll show that I wasn't.

Short, maybe. Frustrated, maybe. Direct, maybe. But certainly 
not "abusive".

This is that whole "semantics" thing, isn't it. I see that my meaning 
necessarily springs from my intent, and I certainly didn't intend to 
be "abusive". Far from it.

Although, I could make the (tenuous) case that when you 
counter-factually assert that I am "abusive", then that's a form of 
abuse! Are you trying to hurt my feelings?

> Ultimately, HTTP was designed in a "hypermedia" era, with largely
> static content. Over 15 years we've managed to bolt on a whole bunch
> of things to make it do what we want, including "web services". The
> result is that people "do what works" - most people get by with GET
> and POST and see no need for anything else. As a result, you will
> probably find very few systems support anything else (one of the
> Google articles linked in the discussion stated that "DELETE" may not
> work past some "firewalls", so they are obviously not RFC compliant).

Consequently, google suggests using POST and putting the "real" verb in 
a X-HTTP-Method-Override header. That's the kind of thing that really 
ticks me off. It's absurd. At this rate HTTP will end up as complicated 
as the, um, *Simple* Mail Transfer Protocol, in short order.

In my "future tense" comments I said I'd show currently "broken" 
semantics. I didn't do that yet. Here:

 http://code.google.com/apis/gdata/basics.html#Updating-an-entry

The whole "X-HTTP-Method-Override" madness aside, see how when you PUT 
an "entry" then the server modifies it before storing it? The server 
doesn't PUT your content at all.

My question is simply why is that conflated API, which you have to 
program directly with some web client toolkit, better than this:

<form action="/entry-service" method="POST">
  <input name="id" />
  <input name="edit_link" />
  <input name="updated" />
  <input name="author_name" />
  <input name="author_email" />
  <input name="title" />
  <input name="content" />
</form>

My answer: it's not. More than that: it's far worse.

> The only reason you seem to be arguing that you should consider PUT
> or DELETE at all is because of keeping with the original semantics of
> HTTP and REST. As mentioned by others there are some benefits in
> terms of cachability, as designed into HTTP, and one of the apparent
> tenets of REST. But cacheability is only of benefit for immutable
> data in HTTP - all changes have to get sent back upstream with the
> intermediate caches/proxies invalidated.

That whole caching thing is far more difficult than you think. I haven't 
had the time to open up that can of worms.

Anyway, as soon as you have authenticated users, or if you use cookies 
(for session identity -- which REST doesn't support, but for which you 
really need to disable caching), then caching stops working.

"Note that section 14.8 normally prevents a shared cache from saving and 
returning a response to a previous request if that request included an 
Authorization header."

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8

> I vaguely remember using PUT for file uploads at one point, but you
> can do the same with POST. Some Content Management Systems may use
> PUT and DELETE for uploading though, for "file-oriented" resources.
> So in terms of current "web 1.0" applications, there is little
> fundamental need.

The really, really, simple point that I wanted to make is probably: I 
think that *all* web applications should be accessible via the web 
browser (without javascript). That's why I stressed the importance of 
hypermedia.

The exception would be WebDAV clients. I think if you're using PUT and 
DELETE you should only be doing so in the context of a WebDAV system.

> In terms of "web services", things are a little different, since you
> have greater control over the client or browser. But I would argue
> that existing approaches to managing the exchange of data in a
> distributed fashion are largely inadequate and likely to be
> superseded in 5 years. JSON is fairly insecure, so I would be
> enforcing a lot of additional input and output validation if I were
> to go down that path. (I assume people are using JSON as an
> light-weight, asynchronous alternative to fully blown SOAP which is
> too heavy-weight and RPC-oriented)

My suggestion: stick with POST and HTML forms based interfaces. These 
are still programmable, and they're trivially simple to implement. 
That's a Good Thing.









-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx
If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.