Ruby
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Methods and Blocks
-
Section 4: Object-Oriented Ruby
-
Section 5: Metaprogramming
-
Section 6: Working with Data and Files
-
Section 7: Ruby Frameworks Overview
-
Section 8: Ecosystem and Testing
-
Section 9: Practical Projects
-
Section 10: Interview Practice
-
Section 11: Data Structures and Algorithms in Ruby
-
Section 12: More Practice Exercises
-
Section 13: Enumerable and Functional Style
-
Section 14: More OOP Practice
-
Section 15: More Testing
-
Section 16: Enumerable and Comparable Modules In Depth
-
Section 17: Ruby Standard Library: Core Utilities
-
Section 18: Ruby Standard Library: Data and Security
-
Section 19: Ruby Standard Library: CLI and Text
-
Section 20: Ruby Networking
-
Section 21: Ruby on Rails Deep Dive
-
Section 22: Ruby Metaprogramming Deep Dive
-
Section 23: Ruby Design Patterns
-
Section 24: Ruby Concurrency
-
Section 25: Ruby Testing Deep Dive
-
Section 26: Ruby Gems and Packaging
-
Section 27: Ruby Performance
-
Section 28: More Practice Exercises
-
Section 29: More Interview Practice
-
Section 30: Rails API Development
-
Section 31: Rails Authentication and Authorization
-
Section 32: Rails Testing Deep Dive
-
Section 33: Rails Performance
-
Section 34: Rails Deployment
-
Section 35: Sinatra and Lightweight Ruby Web Apps
-
Section 36: More Ruby Language Deep Dive
-
Section 37: Ruby 3.x Modern Features
-
Section 38: More Data Structures in Ruby
-
Section 39: More Practical Projects
-
Section 40: Ruby Ecosystem Tools
-
Section 41: More Practice and Review
-
Section 42: Final Practice and Mastery
-
Section 43: Ruby Interview Deep Dive
-
Section 44: Ruby Background Processing Deep Dive
-
Section 45: Ruby GraphQL
-
Section 46: Ruby Object Model Deep Dive
-
Section 47: Ruby Hanami Framework Overview
-
Section 48: Ruby gRPC and Protocol Buffers
-
Section 49: Ruby Data Processing
-
Section 50: Ruby Search Integration
-
Section 51: Ruby File Upload and Media
-
Section 52: Ruby Email and Notifications
-
Section 53: Ruby Admin Panels
-
Section 54: Ruby Feature Flags and Experimentation
-
Section 55: Ruby Monitoring and Observability
-
Section 56: Ruby Docker and Deployment Deep Dive
-
Section 57: Ruby Security Deep Dive
-
Section 58: More Advanced Metaprogramming
-
Section 59: More Final Projects
124: API Versioning in Rails
One of the scariest things about maintaining a production API is the "breaking change." You want to rename a field for clarity or restructure a JSON response to be more efficient, but you know that the second you deploy that change, every mobile app or third-party integration relying on your API will start crashing. This is why we version.
In Rails, there are a few ways to handle this—via headers, query parameters, or URL paths. I've always found URL namespacing (e.g., /api/v1/books) to be the most transparent and easiest to debug. Let's build a small Book Catalog API to see how this works in practice.
Defining the first stable version
Let's assume we have a Book model. For our first version, we'll keep it simple. I want the API to return a list of books with their titles and the author's name.
First, I'll set up the routes. I'm wrapping everything in an api scope and then a v1 namespace:
# config/routes.rb
Rails.application.routes.draw do
namespace :api do
namespace :v1 do
resources :books, only: [:index, :show]
end
end
end
Now, I'll create the controller. Since it's namespaced, the file needs to live in app/controllers/api/v1/books_controller.rb and the class must be nested within the corresponding modules.
# app/controllers/api/v1/books_controller.rb
module Api
module V1
class BooksController < ApplicationController
def index
@books = Book.all
render json: @books.map { |b| { title: b.title, author_name: b.author } }
end
end
end
end
The "Oops" moment: Namespace Mismatches
I've done this a hundred times, and I still do it: I just tried to run a request to /api/v1/books and got a AbstractController::ActionNotFound error. I looked at my controller and realized I had named the class BooksController but I forgot to wrap it in the module Api and module V1 blocks in the actual file. Rails is very strict about the directory structure matching the module nesting. If the file is in api/v1/, the class must be Api::V1::BooksController.
I fixed the nesting (as shown in the code block above), and suddenly, everything worked. Always check your module nesting first when you see a "Controller not found" error in a namespaced route.
Introducing V2 without breaking V1
Now, imagine the business requirements change. We want the API to return a summary of the book, and we've realized that author_name is redundant—we just want to call it author. If I change V1, I break the old apps. Instead, I'll spin up V2.
I'll add the new namespace to my routes:
# config/routes.rb
namespace :api do
namespace :v1 do
resources :books, only: [:index, :show]
end
namespace :v2 do
resources :books, only: [:index, :show]
end
end
Then, I create a new controller at app/controllers/api/v2/books_controller.rb. To keep things DRY, I could inherit from the V1 controller, but usually, when you're versioning, the logic diverges enough that it's cleaner to just inherit from ApplicationController and share logic via Concerns if needed.
# app/controllers/api/v2/books_controller.rb
module Api
module V2
class BooksController < ApplicationController
def index
@books = Book.all
# In V2, we rename author_name to author and add summary
render json: @books.map { |b| {
title: b.title,
author: b.author,
summary: b.summary
} }
end
end
end
end
Now we have two parallel universes. Old clients hit /api/v1/books and get the old format. New clients hit /api/v2/books and get the updated data. I can now monitor the V1 logs, and once I see that traffic has dropped to zero, I can safely delete the v1 folder and routes.
📋 Practical Task
Exercise: Implementing V2 for the User Profile API
You are maintaining a User Profile API. Currently, v1 of the UsersController returns a single field: full_name.
Your task is to implement v2 of this API. In v2, the full_name field should be removed and replaced with two separate fields: first_name and last_name. Additionally, v2 should include a member_since date.
- Update
config/routes.rbto include thev2namespace for users. - Create the
Api::V2::UsersControllerin the correct directory. - Implement the
showaction inv2to return the new JSON structure (first_name, last_name, member_since). - Ensure that
Api::V1::UsersControllerremains untouched and continues to returnfull_name.
There are no comments for now.