As someone who has built APIs on node+express, I love it for small lightweight API's that require very little processing beyond getting data from a database and returning it.
I have gone through much frustration though when I needed to use it for an API that required processing that only made sense to handle synchronously. At that point, it becomes less practical.
Also consider using Connect (on which Express is built) as an in-between point. You get stuff like the Sinatra-style routing, but without the presentation-tier stuff like template support, etc. I've had good luck with it, FWIW.
I second this recommendation. Restify is targeted at APIs so it has built in support for things like API versioning, auto content negotiation and observability (via DTrace). This is not to say that express is bad or that you can't build APIs using express but rather that I find restify more enjoyable to use for APIs.
I recommend express simply because more people know about it. This really matters in an ecosystem so young as node. Information is very hard to get. Hint : compare the number of express and restify blog posts.
Note : I do use testify and its great.
In addition, if you want to take you rest a pi server to also provide web pages, express is more suitable.
If you're building REST APIs with Express and MySQL, check out this project I'm working on called Epilogue: https://github.com/dchester/epilogue
With Epilogue, once you define your models (with Sequelize), from there it's easy to get basic CRUD functionality and endpoints in a few lines of code.
You should not use '*' in dependencies ever! As history changes your app WILL break.
app.configure is also no longer needed. Just configure everything at the top level. If you have different config based on environment, use an if statement or some flag off the process.env
It would be a nicer example to use "pretty SEO URLs" for the individual post resources instead of a GET variable. I know even the Hacker News website goes against this, but it just looks more professional/polished to me, i.e.
I have gone through much frustration though when I needed to use it for an API that required processing that only made sense to handle synchronously. At that point, it becomes less practical.