Teach a Dog to REST

Forward (http://getfwd.com) employs conventions like this between the template and model layers of an MVC style framework.

    get("/accounts") // collection
    get("/accounts", [limit => 10, page => 3]) // pagination
    get("/accounts/email@address.com") // single record
    get("/accounts/email@address.com/orders") // relations
    get("/accounts/email@address.com/orders/10234/items/6/price") // deep relations
    get("/accounts", [search => "john"]) // search
    get("/accounts", [fields => "name, email"]) // partials
    get("/accounts", [order => "name desc"]) // sorting
    get("/accounts", [login => [...]]) // special conventions
    post("/accounts", [alternate_email => $alt, ":validate" => [required => [alternate_email]]) // validation
    put(...) // pretty much what you expect
    delete(...) // same

The interesting thing about moving REST conventions to the model layer, is that you can suddenly create external facing APIs in various formats really easily. I'm hoping/expecting this will become a more common pattern.

Does anyone else find the dual role of POST as a create verb and as "complex search criteria" verb problematic? The WebDav RFC defines a SEARCH verb; why don't we see it used in more REST HTTP APIs?

I love that I've learned most of these best practices already because I use Rails. A good technology (or framework) teaches people how to do something better.

This is a nice presentation about URL best practices, but it doesn't really get into the most relevant or interesting topic of RESTful API design which is resource design representation. I'd love to see more in these specific areas with concrete examples of the approach others have taken.

.json in the resource identifier? "Verbs are bad", except when it's "search"? /v1/dogs/molly vs. /v2/dogs/molly ?

Colour me unconvinced! I don't really see how promoting this hacky form of REST moves us forward.