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