Monthly Archives: August 2013

What Are RESTful Resources?

In learning Ruby on Rails I have heard over and over again about RESTful resources. They are mentioned in every text, they were mentioned in my course, they are mentioned online …but I found the concept hard to grasp.  In most learning environments it was glossed over, so I assumed everyone else understood it but me.

It appears to be an abstract concept, so the explanations are all abstract – but here I go trying to make a simpleton explanation for simpletons. Considering I don’t fully understand it myself, this might not be correct…

What REST stands for
Representational State Transfer

What the hell does that mean?
So, as we know, browsers initiate requests to servers, servers process requests and return appropriate responses. These requests and responses are built around the transfer of representations of resources.

A resource is whatever it is that you want to see. So it could be a book, a user, a product, whatever.

A representation, is just the document that captures and displays the state of that resource.

Representational State Transfer describes how the application will show you the different ‘states’ of the resource you want.

But what does that actually mean for my app?
It seems to mean that in RESTful applications, resources will be identified by a persistent identifier (i.e. the URI will always be the same for a resource.)

These resources will be able to be manipulated using a common set of verbs: the HTTP ones we use in Ruby on Rails are POST, GET, PUT and DELETE. (Which are like Create, Retrieve, Update, Destroy).

You should also be able to access multiple format representations of the same data (i.e. both a JSON and an XML representation of a blog post).

What do you think? Is that right?


Leave a reply

Deploying to Heroku for Beginners

Well, obviously I have not updated this blog in many weeks – and it isn’t because I have abandoned coding, but actually because I have been doing so much of it.

Twice a week I have been going to my General Assembly classes, but I have also attended a couple of Ruby on Rails Oceania nights (RORO) and a Development Hub run by reInteractive. The last two weeks in particular I have been working on my GA Final project – a web app I’m calling Queue. Queue is a social App for connecting with your friends about restaurants you’ve been to, but unlike normal restaurant review sites, it allows you to create a queue of restaurants you want to go to. You also can also recommend restaurants for your friends to go to (I am currently trying to implement this feature).

Anyway, I just deployed this app on Heroku and you can check it out here. Note that I haven’t put much seed data into it, there are likely some bugs, AND there are a million and one features I still want to add.

Now, just a bit about Heroku so that when I deploy my next app I’ll remember what to do. (I’m thinking my next app will be an iteration of this one, which will be focussed on High Teas around the world, since my friends and I have a record of over 30 we have been to).

How to Deploy to Heroku

1. Make sure that your app repository is a whole git repository of its own, and is not part of a bigger repository. For example, you can’t deploy just part of an existing repository to Heroku. This might require you to make a whole new copy of your app in a different location, and make a new git repository for it.

2.  Sign up for a free Heroku account

3.  $ heroku create

4. To move from your development environment to production on Heroku, you will need to change your Gemfile in a few ways.

First, you can’t use SQLite in Heroku production, you will need to use PostgreSQL.

Second, if you are using Rails 4, you will need to add Rails_12factor to your Gemfile – whilc will enable features such as static asset serving and logging on Heroku.

Finally, by default, your app’s web process runs rails server, which uses Webrick. this is fine for testing, but for production apps you need something more robust. A Heroku recommended webserver is Unicorn.

These changes should look like this in your GemFile

group :production do

gem 'pg'

gem 'unicorn'

gem 'rails_12factor'


group :development, :test do

gem 'sqlite3'


5. Then you need to run $ bundle

6.  $ git push heroku master

7.  $ heroku run rake db:migrate – do this whenever you change the database.

8. Whenever you make changes to the database at all, you should use $ heroku restart

9. Running $heroku open from the command line will open it up in the browser. You can also go to your heroku account, open the new app in your dashboard, then click on the ‘open in new window’ icon next to its name.

If you want to later clear out your database information (e.g. if you deployed it and then were messing around with fake data in there like I was), you can do these
First drop and create the database
heroku pg:reset DATABASE
Then migrate in the tables
heroku run rake db:migrate
Other tips

  • To check out what is going on with your web app, you can use $ heroku logs.
  • If you have seed data you want to use, run  $ heroku run rake db:seed

I think that’s it. Anything I’ve missed (for beginners?).



Leave a reply