views:

53

answers:

1

I think there is a wide consent that is a good practice to separate your REST API from your main website. The main reason is that you can scale your API and website independently of each other.

Additionally, Rails has a lot of middleware that is not required for stateless services (e.g. sessions, cookies, view rendering, etc...). Jeff Dean has a good write up on how to remove all of this middleware (http://pivotallabs.com/users/jdean/blog/articles/1419-building-a-fast-lightweight-rest-service-with-rails-3-).

At the moment, I am simply using the new Rails 3 responder (respond_with) in one single application, both for the website and the API. The website is used mainly for administration purposes.

How would you separate the API from the website?

I think an option would be to pack all models in a gem, then have two different applications, one lightweight REST service, and the administration website. They would be hosted on different Heroku instances, but access the same MongoHQ database.

A: 

You have 2 choice

  1. extract your Model ans use it in all of your 2 application
  2. made you API and your application on same application. But you deploy 2 server. One using only your application par and other with your API part. So if you need more API. add more on your API server.

You don't really need extract API. You just need separate it.

shingara