With a user registration, it would function very similar to any other kind of form post that you would do. You should have some sort of registration endpoint within your API application that would create the user. You may have something like http://example.com/users/create where you would make an HTTP POST to via your app. You would pass in the parameters

{
  user: { 
    first_name: 'John',
    last_name: 'Doe',
    email: 'john.doe@example.com',
    password: '123456',
    password_confirmation: '123456'
  }
}

and your model would have the necessary validations to ensure password complexity, and email uniqueness. If the user is created, pass a successful response. Otherwise, you would respond with an error.

You would also need to provide an authenticate method for your user. In this example, we simply used devise to handle the user registration and authentication. While you could do something similar in an API only application, it might be a bit heavy. However, using the devise logic (not necessarily the views), will give you access to a lot of the built in functionality around locking out the user, confirmation signups, etc.

Depending on the architecture of your application, you can make the new user registration only available under the client portal. Also, if you are using some sort of role based authorization, make sure that you set the default access to a client role. 

Hope this helps!

Only if your cache key included the updated_at attribute or similar. Part of the issue is also when you have a collection of records as you might find in Russian Doll Caching. Even if the individual record's cache is expired, you will still need to expire the outer cache (parent cache) as well since it is stale at this point.    

It is a Chrome Extension called Advanced REST Client.

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.