Tutorials or Screencasts on Building a Rest Web Service on Rails

Tutorials or screencasts on building a REST web service on Rails

I wrote 2 blog posts that you'll probably find helpful:

http://davidsulc.com/blog/2011/04/10/implementing-a-public-api-in-rails-3/

http://davidsulc.com/blog/2011/04/17/consuming-a-public-rails-api-with-jquery/

They're not tutorials, but it should get you going.

The basic idea is: expose JSON data through controller actions when a request is made with the .json format.

Cross domain requests (like the ones you'll be doing from your mobile app) are a little trickier, as explained in the blog post: you'll actually need to send javascript within a callback, or your code won't work (you'll get an empty response). (Explained in the first post.)

Once the data is exposed as JSON, simply query it from your mobile app (as explained in the 2nd post).

EDIT: Manning has a book on Rails 3 (one of the authors being none other than Yehuda Katz) with a chapter on creating an API: http://manning.com/katz/ In particular, it covers token authorization for the API using Devise.

Rails 3. How to add an API to a rails app

a good starting point might be reading up on REST and responders

Then to interact with the API from another rails app, you can use ActiveResource. There's a Railscast on it.

An example:

#API side
class ProductsController < ApplicationController
  respond_to :json

  def index
    @products = Product.all
    respond_with(@products)
  end
end

#Client
# models/product.rb
class Product < ActiveResource::Base
  self.site = "http://your-api-app.com"
end

How do you get data from a server via Ruby and then pass this data into Java/Android classes?

The basic idea is to get data by hitting URL on web from your mobile Android app:

You need to just create web services in Ruby that will return you data in the different formats like JSON, HTML, YAML, XML from which you can parse it on your mobile app. Usually we prefer JSON/XML formats data that will be easy to parse on mobile site.

Here you go, for creating RESTful api in Rails there are many tutorials and example are available on web like below:

Tutorials or screencasts on building a REST web service on Rails

http://pivotallabs.com/building-a-fast-lightweight-rest-service-with-rails-3/

http://railscasts.com/episodes/350-rest-api-versioning

http://gavinmorrice.com/blog/posts/21-building-a-rest-api-in-rails-3

http://codedecoder.wordpress.com/2013/02/21/sample-rest-api-example-in-rails/

http://jes.al/2013/10/architecting-restful-rails-4-api/

Zend Framework - Ruby on Rails has a screencast showing how to code a blog in 15 minutes. Does ZF have a similar screencast?

You can checkout ZendCasts.com

However, when deciding between ZF and RoR, you should be aware that they are very different from each other. RoR is a full stack with integrated ORM built on AR and a rather rigid structure. It's powerful and there is lots of magic inside and I'd say it's RAD capabilities are above ZF due to rake being more powerful than Zend_Tool

ZF, on the other hand, is first and foremost a loosely coupled component library with a use-at-will architecture for maximum flexibility. You can use it's components together, but you don't have to. While it does feature convention over configuration, ZF doesn't take you by the hand too much. It expects you know how to walk. Also ZF has no full fledged ORM and no AR, but you can very much integrate Doctrine or Propel or whatever library you like to use.

You often hear folks new to ZF complain about it is hard to get into it, simply because they expect ZF to work like RoR or Symfony or Cake, e.g. a full stack framework

EDIT:

Cake aims to be a port of RoR to PHP. It is built around ActiveRecord. Like CI < v2, it is backwards compatible with PHP4, which means it doesn't fully utilize the OOP capabilities you get in PHP5. I'd say both are easier to get in than ZF though.

is restful meant for web services only OR for both web services AND web pages?

RESTful is commonly used when referring to web services, but it can very well apply to web pages. In a nutshell, being RESTful is about dealing with resources. A resource can be a person, a book, a movie, a theatre, a ticket, or whatever you fancy.

There are four basic operations you could perform on a resource.

• create (POST)
• read (GET)
• update (PUT)
• delete (DELETE)

Most web browsers do not support the PUT and DELETE actions, so you can only use POST actions for sending data. Rails fakes PUT and DELETE by passing in a hidden parameter named _method that the framework picks up and routes it depending on that value.

Also, you should never use GET for any destructive action. Any action that changes the state of your resource(s), should be called with either POST, PUT, or DELETE depending on the change (fake PUT/DELETE with POST if need be).

I would suggest you checkout the way RESTful routing is handled in Rails just to get an idea, if nothing else. Althought the four actions above are sufficient to modify a resource in any way possible, Rails also introduces three other types of actions that sound useful.

• index (listing view of all items)
• new (usually a form view to add a new
  resource)
• edit (usually a form view to
  update an existing resource)

Pretty URL's is definitely on the table when designing RESTful sites, but probably the biggest win is that the quality of code improves automatically. When you're only dealing with resources, and there are only four potential actions that can be applied to a resource, then things start to clean up by themselves.

Edit 1:
Self-descriptive URL's are preferred and will make your life easier, but there's nothing stopping from creating cryptic URLs that uniquely identify a resource and manage it using the HTTP verbs. URLs such as the ones below (using md5) to uniquely identify resources are perfectly RESTful.

// represents a person "John Doe"
http://example.com/4c2a904bafba06591225113ad17b5cec

// represents the movie "Lord of the Rings: The Two Towers"
http://example.com/1d9198260dec7bda3fb21e232d60fec3

// represents the "Formula One" sport
http://example.com/fs340as?id=23xa12&type=SP012Ts

That's REpresentational State Transfer right there. The MD5 hash is like the mailing address of the resource that remains constant. The representation could be the movie's details (in html/xml/json/etc.), or maybe the video of the movie itself depending on the capabilities of the client).

Edit 2:
Let's say you have a resource which is a collection - countries of the world.
It could be represented by a URI and HTTP verb such as:

GET /countries

Since paging is a property of the application rather than the resource itself, you could supply querystring parameters to control it.

GET /countries?page=1

A country is also a resource that is a part of the countries resource. You could identify a country with a URL such as:

/countries/<id>

And operations on this country could be performed with these verbs:

GET    /countries/<id>
POST   /countries  -- the new country has no existing representation
PUT    /countries/<id>
DELETE /countries/<id>

What is a good tutorial / reference for developing apps using Ruby on Rails 2.3.5

http://ruby.railstutorial.org/ruby-on-rails-tutorial-book

You can switch between Rails 3 and Rails 2.3 on the right.

Learning Ruby on Rails

I've been moving from C# in my professional career to looking at Ruby and RoR in my personal life, and I've found linux to be slightly more appealing personally for development. Particularly now that I've started using git, the implementation is cleaner on linux.

Currently I'm dual booting and getting closer to running Ubuntu full time. I'm using gedit with various plugins for the development environment. And as of late 2010, I'm making the push to use Vim for development, even over Textmate on OS X.

A large amount of the Rails developers are using (gasp) Macs, which has actually got me thinking in that direction.

Although I haven't tried it, Ruby in Steel gives you a Ruby IDE inside the Visual Studio world, and IronRuby is the .NET flavor of Ruby, if you're interested.

As far as books are concerned, the Programming Ruby (also known as the Pickaxe) book from the Pragmatic Programmers is the de-facto for learning Ruby. I bit the bullet and purchased that book and Agile Web Development with Rails; both books have been excellent.

Peepcode screencasts and PDF books have also been great for getting started; at $9 per screencast it's hard to go wrong. I actually bought a 5-pack.

Also check out the following:

• Official Rails Guides
• Railscasts
• railsapi.com or Ruby on Rails - APIdock
• The Ruby Show
• Rails for Zombies
• Softies on Rails - Ruby on Rails for .NET Developers
• Rails Podcast
• Rails Best Practices

I've burned through the backlog of Rails and Rails Envy podcasts in the past month and they have provided wonderful insight into lots of topics, even regarding software development in general.

Backbone.js frontend with RESTful Rails backend?

For Client-side frameworks, this article has a list of 20 of them with pro's and con's:
http://net.tutsplus.com/articles/web-roundups/20-javascript-frameworks-worth-checking-out/

Here's the list:

1. Backbone.js
2. Knockout.js
3. Asana luna
4. Cappucino
5. Sproutcore
6. BatmanJS
7. corMVC
8. TrimJunction
9. pureMVC
10. jamal
11. choco
12. sammyjs
13. extJS
14. agilityJS
15. eyeballs
16. activejs
17. spinejs
18. qooxdoo

These are roughly all about creating client-side, ajax-based, javascript MVC frameworks.

If you're looking to start somewhere, then I recommend thinking about Client-Side Templates (...ates...ates...ates) (just the "V") to support a service-oriented architecture (many clients are supported by service-endpoints you create).

It's a new technique that involves modularizing your client-side code, bringing MVC to the client, and let business-logic live in the platform. A lot of Software-as-a-Service applications are leveraging them, and with the increasing sophisticated of javascript libraries and frameworks, as well as browser capabilities with HTML5, CSS3, etc. there's going to be an increasing sophistication in client-side presentation.

So learn it.

What are the benefits?

To paraphrase Linked In: for leveraging browser-caching, de-coupling your front-end client-side presentation, asynchronous load, progressive rendering (for some frameworks), performance, ajax-interaction, and more.

Several great frameworks include:

1. mustache
2. dust.js
3. handlebars
4. Google Closure Templates
5. Nun
6. Mu
7. kite

I highly recommend looking at Linked In's move away from JSP towards Client-Side Templates and why they choose dust.js in Linked In's front-end client-side templates throwdown for a comparison. They go into much greater detail, and research, as to why they changed their stack to support this (it involved using 3 server-side technologies), as well as their comparisons of all the frameworks they could find.

How to write a REST API?

Just to let you know:

I ended up using Ruby on Rails.

EDIT: Since this answer has been downvoted for not providing the reason behind choosing Ruby on Rails and also no instructions on how to write a REST API with it, I thought I would give you my motivation and some simple instructions.

I started reading a book about Ruby on Rails and realized that all I needed to do was to use scaffolding and I got a JSON REST API for free.

Here's a good guide to get you started: http://guides.rubyonrails.org/getting_started.html

When you have your Ruby on Rails environment up and running, creating your REST API isn't harder than running:

$ rails generate scaffold Post name:string title:string content:text

(Example from the above link.) I also found that Rails is very easy and free to deploy to heroku, which meant that I didn't have to pay for hosting for my very basic, low traffic, REST API. There are many other reasons why I am very happy to work with Ruby on Rails, but that's beyond the context of this question.

Rails, live audio/video streaming, recommendations?

We use panda for video streaming. Here is the guide to integrate it with rails

---

Related Topics