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

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



On Wed, 30 May 2007, Nathan de Vries wrote:
> 	GET users/nathan/tiles/1
> 	Host: tilefile.com
> 	Accept: text/html
>
> But when I do this, I get a JSON representation of the same resource:
>
> 	GET users/nathan/tiles/1
> 	Host: tilefile.com
> 	Accept: application/x-json

This is a different discussion... but I've thought long and hard about 
that one, and I think you'd be better served thinking like this:

 	GET users/nathan/tiles/1.html

and

 	GET users/nathan/tiles/1.json

I think it's better. Why? Easy:

 <a href="/users/nathan/tiles/1.html">Tile 1</a>
 (<a href="/users/nathan/tiles/1.json">JSON</a>)

> The verbs implied by HTTP methods PUT, GET, POST and DELETE are
> useful independent of "connectors", but representations aren't
> universally useful. Are you saying that HTML forms are the
> universally understandable representation of a resource, and can be
> used by all kinds of connectors? I don't think so.

I *am* trying to stress the relevance of "hypermedia". There are 
practicalities, too. For instance: XHTML support sucks, and XHTML isn't 
perfect.

I don't understand what you mean by "connectors".

> You're trying to deal with immutable sets by suggesting a "manager
> service" which enforces business logic. I think it's possible to deal
> with business logic while retaining highly granular resource access.

I'm all for "highly granular resource access" *if* you're talking about 
GET.

When it comes to server state mutations, then in my view an information 
system adds value by providing a set of very focused and specific 
functions that do quite a lot more than a single CRUD operation.

> No, I do recognise the value of it...but I also see the inherent
> problems. To integrate with a service you need to resort to scraping
> the HTML and pretending you're a form by POSTing the appropriate
> values.

You don't need to scrape the HTML in order to POST appropriate values. 
Of course, you *could*.

> Don't you see a problem with that?

No, I don't see the problem.

> Why can't the HTML form just be a representation of the resource
> (albeit the most used)? 

That's what I suggested. Back to the original example:

ÂGET /deletion-service

Â<form action="http://example.org/deletion-service"; method="POST">
 Â<input name="doc" />
 Â<input name="id" />
 Â<input type="submit" name="operation" value="delete-chapter" />
 Â<input type="submit" name="operation" value="delete-section" />
Â</form>

The "deletion-service" is a resource, and a hypermedia representation of 
that resource will describe the service interface with a HTML form.

> You're throwing away interoperability to maintain a system you
> understand, rather than recognising that you can retain the existing
> methodologies but enhance them in such a way that much more is
> possible.

I'm not doing any such thing. I'm suggesting that PUT and DELETE should 
only be used to manage files. (And if you want to manage files, just 
install a WebDAV server, and you're done.)









-
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.