The reason why it is displaying the page instead of a JSON response is due to the sample application's routes.

  namespace :api, path: '/', constraints: { subdomain: 'api' } do
    resources :users
  end
  constraints subdomain: ['', 'www'] do
    resources :users do 
      resources :phones
    end
    root 'users#index'
  end

In the example application's routes, there is a constraints on the subdomain where if it is empty, it will default to the web view of the application. If you're using an API only, you can remove the constraints block as well as the constraints on the subdomain: 'api'. So your routes may look something like

Rails.application.routes.draw do
  post 'user_token' => 'user_token#create'
  devise_for :users
  namespace :api, path: '/' do
    resources :users do 
      resources :phones
    end
  end
end

You have a few options on how to handle something like this. You could handle it on the server side with a model scope to check each individual day. However, that could be more taxing on the server if a calendar had several events; not to mention that you're calling the scope about 30 times per calendar view. An alternative would be to leverage client side calculations for the number of events. However, you could still run into issues with the client side taking a while to calculate the number of events.

Would your case use be for a smaller summary calendar? I know that the current version of FullCalendar does have a scaling feature where it will gracefully hide events and display a number of events for that day.

Gotcha. It does make sense.

In that case, I would send an additional parameter with the JSON response of whether or not a day is blocked (which is calculated on the server side).

You can use the dayRender callback to change the color of a particular day based on the blocked days. Depending on how you are allowing new event creations, you would want to handle the validation there as well as the backend on the model.

This does get a bit tricky since you're having to validate on server side and render on client side as well.

Also check out this JSFiddle where they're adding a class to a date, dynamically, after the calendar is rendered.

Yeah, I'd calculate it on the server side and then pass the blocked days through the JSON render request. On the client side, put in the results of the client side validation. Overall, you just want to make sure that you're aren't allowing a client to go through a whole event record creation, only to tell them something that you already knew and could have told them from the beginning; that enrollment for that day is already filled.

You could do something like this

class LeaveEvent < ActiveRecord::Base
  scope :events_on_date, -> (date)  { where('start_time <= ? AND end_time >= ?', date, date).size }
  ...
end

Then use the scope within the JSON builder.