Development Seed’s CMS-Free Approach

Found this interesting company, called Development Seed, that was talking about building static, no-cms sites.

They do work for some big clients. They also have their hand in a lot of analytical, data-based design. Just look at the front of their website.

They are currently working on healthcare.gov. Here’s some word from the trenches on building that sort of large-scale, accessible, static website.

As an interesting side note, consider the case study of Obama’s Fundraising campaign which was also CMS-free.

Development Seed also run this thing called MapBox which allows you to do customized maps without Google (a win).

They also designed their own (free) icon set for maps, called Maki.

They also build and support an application called TileMill for generating these types of maps. It’s looks pretty easy to use and is based on open-source technology.

Their site led me to Leaflet.js which is an open source JavaScrip interactive mapping library that they are now using with MapBox.

Practical RESTlike Routing without PUT and DELETE

I have a proposal, a compromise, if you will.

RESTful API’s and web applications are all the rage these days. Ruby on Rails has popularized it to no end. On paper REST is a great idea, but jumping through the hoops of sending and receiving HTTP methods other than GET and POST is sometimes not worth it. I’m building an MVC web app in PHP and wanted to adopt some good conventions, but not become too much of a stickler to adhere to REST.

The RESTful standard

Let’s first have a look at an example of standard (RESTful) Rails routing:

HTTP Verb Path action used for
GET /photos index display a list of all photos
GET /photos/new new return an HTML form for creating a new photo
POST /photos create create a new photo
GET /photos/:id show display a specific photo
GET /photos/:id/edit edit return an HTML form for editing a photo
PUT /photos/:id update update a specific photo
DELETE /photos/:id destroy delete a specific photo

Proposed RESTlike convention

Now if we want to avoid using PUT and DELETE we have to map those to either GET or POST. REST stipulates that GET requests should not be used to update the resource, so let’s replace PUT and DELETE methods with POST. Using the previous table as a framework yields the following.

HTTP Verb Path action used for
GET /photos index display a list of all photos
GET /photos/new new return an HTML form for creating a new photo
POST /photos/new create create a new photo
GET /photos/:id show display a specific photo
GET /photos/:id/edit edit return an HTML form for editing a photo
POST /photos/:id update update a specific photo
POST /photos/:id/delete destroy delete a specific photo