RESTful applications

[Sean Davis]

REST gets a lot of press these days, it seems.  However, I haven't found many examples of how it works in practice.  It seems that put and delete methods need to be called via XMLHttpRequest (AJAX).  That means changing the way that at least I think about web applications.  No longer is it a matter of taking input from the user (client) and generating a new page, but parts of the page must be generated and/or updated separately.  So, I'm just curious how other people would go about a simple application like an address book using RESTful design and AJAX, particularly from the point of view of dispatch, templating (and what form returned output takes)?  I know this is a vague question, but I am just beginning to grasp some of these concepts and would appreciate if someone could provide some guidance/insight.

Thanks again,
Sean

[Bob Ippolito]

I think most people stick to GET and POST. Not all XMLHttpRequest
implementations will even do PUT and DELETE properly.

The important parts of REST from a practical standpoint are the URLs
and the usage of GET for (only) idempotent requests. Pylons makes it
pretty easy/obvious to do these right.

-bob

[Robert Ian Smit]

> REST gets a lot of press these days, it seems. However, I haven't found
> many examples of how it works in practice. It seems that put and delete
> methods need to be called via XMLHttpRequest (AJAX).

Pylons and some other frameworks can work with browser-unsupported HTTP
verbs by using a hidden input field. The formcontents are POSTed to the
server as usual, the framework will see the hidden field and translate
it to the proper call in the application, i.e.:

<input type="hidden" name="_method" value="DELETE" />

Also have a look at the Routes documentation[1] concerning REST.

To request a form representation of a resource (for preparing edits
that can be PUTted) map.resource from Routes (and others) suggests
adding ';edit' to the URL. For instance a request to /foo/1;edit should
result in a form.

Combined with a hidden "_method" input field it is possible to use
RESTful operations with classic POST and redirect interaction between
browser and server. No AJAX or any Javascript is required for this.

I'd like to add one question of my own. Should there be a "Are you sure
you want to delete?" representation added to map.resource? It's easy to
add a member but shouldn't the framework offer a convention?

[1] http://routes.groovie.org/manual.html#restful-services

[Sean Davis]

Thank.  This clarifies a lot for me.  I have tried using the map.resource() methods and the hidden field method for performing a delete, for example.  Under pylons, does the translation from the hidden field to http method happen before dispatch via routes?  It seems like it isn't happening, as when I have html that looks like this:

 <td><form method="post" 
action="/talks/1" class="button-to"><div><
input onclick="return confirm('Are you sure?');" type=
"submit" value="Destroy" /></div></
form></td>

And a map.resource('talk','talks') with a talks.py controller and a delete(self,id) method, I get an error and the method on the debug page says "POST".  Any thoughts?

Thanks again,
Sean

[Ian Bicking]

Sean Davis wrote:

It might be nice to do this method fixup in middleware, similar to
PrefixMiddleware (or maybe expand that to a general FixupMiddleware --
I'd like to move that out of Paste Deploy and into Paste anyway).

--
Ian Bicking | ia...@colorstudy.com | http://blog.ianbicking.org

[Ben Bangert]

On Jan 1, 2007, at 7:02 AM, Sean Davis wrote:

> Thank. This clarifies a lot for me. I have tried using the
> map.resource() methods and the hidden field method for performing a
> delete, for example. Under pylons, does the translation from the
> hidden field to http method happen before dispatch via routes? It
> seems like it isn't happening, as when I have html that looks like
> this:

As Routes does the lookup for controller/action, it does do the
_method check.

> <td><form method="post"
> action="/talks/1" class="button-to"><div><
> input onclick="return confirm('Are you sure?');" type=
> "submit" value="Destroy" /></div></
> form></td>

If you the helper method h.form(), you can give it a put/delete
method and it will create the appropriate hidden fields, ie:
h.form(h.url_for('talk', id=1), method='delete')

> And a map.resource('talk','talks') with a talks.py controller and a
> delete(self,id) method, I get an error and the method on the debug
> page says "POST". Any thoughts?

I'm guessing this is because a POST to a individual resource is
meaningless in RESTful applications. You can PUT to a specific
resource to update it, DELETE the resource, or GET the resource.
Under a typical RESTful setup, you POST to the resource collection to
add new members. (Atom Publishing Protocol serves as the best model
for a RESTful app I believe, which is what this setup duplicates).

HTH,
Ben

[Ian Bicking]

Ben Bangert wrote:
>> And a map.resource('talk','talks') with a talks.py controller and a
>> delete(self,id) method, I get an error and the method on the debug
>> page says "POST". Any thoughts?
>
> I'm guessing this is because a POST to a individual resource is
> meaningless in RESTful applications. You can PUT to a specific resource
> to update it, DELETE the resource, or GET the resource. Under a typical
> RESTful setup, you POST to the resource collection to add new members.
> (Atom Publishing Protocol serves as the best model for a RESTful app I
> believe, which is what this setup duplicates).

POST isn't meaningless; PUT can only be used for direct updates on an
object, everything else is done as a POST. PUT can also be used to
create objects; APP doesn't use that, because it lets the store control
the URL space, but in contrast WebDAV does use PUT to create resources.

POST might be used for simple kinds of updates -- e.g., increment a
counter -- or other kinds of control situations. It's not particularly
unRESTful IMHO.

[Ben Bangert]

On Jan 1, 2007, at 11:05 AM, Ian Bicking wrote:

>> I'm guessing this is because a POST to a individual resource is
>> meaningless in RESTful applications. You can PUT to a specific
>> resource to update it, DELETE the resource, or GET the resource.
>> Under a typical RESTful setup, you POST to the resource collection
>> to add new members. (Atom Publishing Protocol serves as the best
>> model for a RESTful app I believe, which is what this setup
>> duplicates).
>
> POST isn't meaningless; PUT can only be used for direct updates on
> an object, everything else is done as a POST. PUT can also be used
> to create objects; APP doesn't use that, because it lets the store
> control the URL space, but in contrast WebDAV does use PUT to
> create resources.
>
> POST might be used for simple kinds of updates -- e.g., increment a
> counter -- or other kinds of control situations. It's not
> particularly unRESTful IMHO.

I was referring to using a POST against a member resource. Not POST
in general. Of course, who knows if the Restafarians would consider
WebDAV a RESTful service. The REST religion has many branches, they
don't always agree. :)

Cheers,
Ben

[Sean Davis]

I'm sorry, Ben.  I posted only the form tag, not the accompanying hidden field.  I did use h.form() with method as "delete".  It sounds like this should "just work", so I must be doing something wrong at some point.  I'll play with it a bit more. 

I just wanted to clarify that Routes would see (or interpret) a form with a POST method with a hidden field with name "_method" and value "delete" as a delete method, for the purposes of dispatching.  It sounds like that is what is supposed to happen.

Sean

[Ian Bicking]

Ben Bangert wrote:
>> POST might be used for simple kinds of updates -- e.g., increment a
>> counter -- or other kinds of control situations. It's not
>> particularly unRESTful IMHO.
>
> I was referring to using a POST against a member resource. Not POST in
> general. Of course, who knows if the Restafarians would consider WebDAV
> a RESTful service. The REST religion has many branches, they don't
> always agree. :)

I believe the guy who coined "REST" was one of the authors of the WebDAV
spec. And I think it's a good enough spec. But the use of GET in
WebDAV sucks royally, and it's something noticeable in other REST
practices too -- they don't leave enough room for UI (aka web applications).