[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:
> On Wed, 2007-05-30 at 13:32 +1000, John Elliot wrote:
> > I don't understand what you mean by "connectors".
>
> Read Fieldings' dissertation again.

I couldn't bear to read it again. I've read the whole thing from end to 
end, twice; and I've spent a lot of time on the rest-discuss list, and 
talking about it with a number of people in different circles. I think 
it has a few major short-comings, and I've already taken all the value 
from it that I can.

What do *you* mean by "connectors" when you say: "The verbs implied by 
HTTP methods PUT, GET, POST and DELETE are useful independent 
of "connectors", but representations aren't universally useful."

You mean to discount 'middleware', such as web proxies?

You assert that PUT and DELETE are useful, and I assert that they're 
not. Thinking in those terms will lead to shoddy interfaces, in my 
view. That's because side-effects should go via business logic, and 
business logic is not CRUD.

> > You don't need to scrape the HTML in order to POST appropriate
> > values. Of course, you *could*.
>
> You do if you know nothing of the service.

No, you don't. You could read the documentation, for instance.

> You want to integrate with a calendaring or bookmarking service?
> You'll need to parse the HTML form to know what fields the service
> you're POSTing to expects. Which form? Who knows.

In addition to being discoverable via hypermedia (and already 
interactive through a browser) there can be documentation, *obviously*.

You don't have a solution that just magically removes the need for API 
documentation by mere virtue of using PUT and DELETE. Quite the 
contrary: you don't have any form of interface description.

> I much prefer the idea that if I know where a resource is or where
> I'd like it to go, I can put it there, update it and delete it
> without knowing which "manager" resource in the system can act as a
> broker for my desired interactions.

So, you want a file-system. Install a WebDAV server.

> > > Why can't the HTML form just be a representation of the resource
> > > (albeit the most used)?
> >
> > That's what I suggested.
>
> You seem to be suggesting that forms should be the *only*
> representation of a resource, not one of many.

I'm not sure what gave you that impression.

I said that service interfaces should be expressed via hypermedia.

> > I'm suggesting that PUT and DELETE should only be used to manage
> > files.
>
> My understanding of resources/URIs in the context of REST is
> staggeringly different to yours, then.

So it would seem.

FWIW, I spent a lot of time reading about and thinking about REST, and 
decided in the end that I didn't care that much about it. It's valuable 
to understand some of its ideas, but that's about it.

I think that the "REST is CRUD on URIs" meme is a gross 
misunderstanding, and certainly not how to design web services.









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