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

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



OK, I understand where you're coming from now.

In short, I don't think that HTML forms should become the standard
"schema" for defining what can and can't be done to a remote resource.
Certainly, a HTML form representation of a resource is valuable (for
browsers) but as soon as you break out of the "browser" world there are
immediate problems.

I'll give an example that I work with every day . Tilefile is a system
for managing resources, which consist of Tiles (media), Users, Grids
(collections of Tiles) etc. When I do the following I get an HTML
representation of my Tile resource:

	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

Not only do I get the representation, but I also get URIs to other
resources, such as the owner's URI, URIs of comments etc.

What does this mean? If we want to build a client for the mobile,
desktop or otherwise, in any language or environment we can do so very
rapidly without requiring support for HTML forms. When you want flash
clients, java clients, embedded systems etc. all accessing the same
resources, the forms-only world you speak of isn't an option.

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.
	
> > Surely the resources nested in the "from_today" resource set can be
> > deleted?
> 
> No way. You don't really think that's true, do you?

Yes. You might not be able to remove the resource *from the set*, but
you can certainly remove the resource itself. Doing so will (indirectly)
remove it from the set. What about a better example, with a mutable set:

	GET /news/categories/geeky_stuff
	Host: example.com

	=> 200 OK
	URI: www.example.com/news/article1
	URI: www.example.com/news/article2

	PUT /news/categories/geeky_stuff
	Host: example.com

	URI: www.example.com/news/article1

	=> 200 OK

The "from_today" resource is immutable, so what? Attempting to edit it
should be dealt with by presenting an appropriate server error code and
(hopefully) a readable error of some kind. In the case of a category,
editing makes sense so you allow the appropriate methods to be called.
Simple.

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.

> You don't recognise the value of hypermedia and the deployed
> infrastructure of HTML forms, and thus your actions are going to have
> the effect of watering down that value.

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.
Don't you see a problem with that? Why can't the HTML form just be a
representation of the resource (albeit the most used)?

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.


Cheers,

--
Nathan de Vries


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