Who GETs REST?

Tweet

Prompted by looking at Catalyst and Handel in particular, has me thinking about that whole REST thing again.

Seems to me that very few people get the point (and I’m not claiming I do). There’s been alot of smart debate, some even down to earth, but what does REST really mean? What are practical consequences web developers can use? How do we eliminate grey areas? Is this REST?

What I’m pretty sure of is what Roy was describing is, at heart, a very simple set of ideas, based on a simple protocol that provides everything you need. But in the endless debate vs. SOAP the point seems to have been lost.

One particular quote from the Wikipedia interpretation

With REST [...] the emphasis is on the diversity of resources, or nouns

Turning that on it’s head, how about this as a bold statement that we can actually use:

Never put verbs in URLs

To that extent made this change so that this URL – http://www.example.org/users/search?surname=Michaels becomes this: http://www.example.org/users?surname=Michaels

Will kick off with two exceptions (but I think the only exceptions) – domain names or where the verb is actually part of the name (such as a title in a “search engine friendly” URL) like this

Think the consequences which fall out of that rule could make frameworks much easier to use if APIs get designed around it – a middle ground between this and frameworks like Catalyst and Rails which I think have inverted the problem into this form.

In Catalyst terms that boils down to controllers like;


package MyApp::Controller::Cart::Item;

use strict;
use base 'Catalyst::Base';

sub new : Regex('^(d+)$') {
     my $class = shift;
     my $self = Catalyst::Base->new();
     bless($self, $class);
     return $self;
}

sub GET {
    my ( $self, $c ) = @_;
    # Do HTTP GET stuff here
}

sub POST {
    my ( $self, $c ) = @_;
    # Do HTTP POST stuff here
}

sub DELETE {
    my ( $self, $c ) = @_;
    # perhaps...
}

Will leave it there. Feel free to POST flames or whatever

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.realityedge.com.au mrsmiley

    Like you said, few people get the point, myself included. SOAP does well enough for my needs, but then I’ve never looked into REST to figure it all out for myself.

    I’m not sure what the basis is for removing verbs from the urls though. Would you include frameworks that typically accept something akin to an “action” parameter? It is basically your verb after all. http://www.example.com/?action=search or translated as http://www.example.com/?verb=search. You’d be hard pressed to find a way to translate said url without using any verbs in the urls considering it doesn’t contain any other parameters you could refactor.

    I’m also assuming that the above only applies to GET requests and not POST?

  • http://www.phppatterns.com HarryF

    Like you said, few people get the point, myself included. SOAP does well enough for my needs, but then I’ve never looked into REST to figure it all out for myself.

    That’s a fair point of view. Think the two obvious benefits of REST over SOAP for system-to-system data exchange are REST makes it easier to use the network efficiently – e.g. you can use HTTP cache headers and having very general methods like GET and POST discourages fine grained APIs (which don’t translate well to networks) plus you will probably be able to inspect a REST service with a browser.

    But was thinking more of CRUD-style frameworks and normal HTML interfaces.

    an “action” parameter? It is basically your verb after all. http://www.example.com/?action=search or translated as http://www.example.com/?verb=search.

    What about this URL http://www.example.com/results?term=PHP ?

    Kind of evading the question there suffice to say another consequence is seperating “tools” for working with “resources” from the resources themselves. That might mean to edit a blog entry you might have a URL like http://www.example.com/backend/editor which displays the form you need and POSTs to the resource (URL) to update it.

    I’m also assuming that the above only applies to GET requests and not POST?

    Guess the encoded POST data might contain verbs but not the URL you POST to.

  • Pingback: SitePoint Blogs » MVC and web apps: oil and water

  • Magic8Ball

    I’m looking for an XML description of a REST service, something like WSDL is there such a thing ?

  • Mazr

    IMO, it would be even better if you could somehow eliminate the query string to get something like:

    http://www.example.org/users/surname/Michaels
    http://www.example.org/articles/term/PHP

    This would make the search URIs more inline with tag URIs:

    http://www.example.org/articles/tag/PHP

    Of course, browsers don’t normally generate URIs like this from forms so you’d need a JS or server rewrite/redirect to get URIs like these.

  • zndyhhcemz
  • cbmeeks

    I still don’t understand why verbs in URLs are bad. delicious does it and they seem pretty successful?

    I plan on releasing (yet another) image hosting site. eBlarg!

    I hope to structure my URLS like:

    View all pictures in “Florida” gallery with “Swimming” and “Diving” tag:
    http://cbmeeks.eblarg.com/pictures/gallery/florida/swimming/diving

    “pictures” would be the class, “gallery” would be the function and the tags would follow.

    I think this follows the “no verbs” method but I plan on doing this for tags:

    Edit tag:
    http://cbmeeks.eblarg.com/tags/edit/florida

    IMHO, the end user (who cares less about REST) can easily remember that URL and it makes sense to THEM.

    Anyway, just my opinion.

  • cbmeeks

    Strike what I said back in May.

    I’ve spent the last couple of months getting a much better understanding of REST.

    And delicious uses a REST-RPC hybrid anyway. :-)
    http://www.signaldev.com