In this lesson, you’ll learn about: multi-format responses, JSON serialization, and building clean, reusable Rails API controllers1. Multi-Format Controller ResponsesUsing Ruby on Rails:🔹 Problem:
Different clients need different formats
Browser → HTML
Mobile app → JSON
External systems → XML
🔹 Solution:
Use respond_to
def show @user = User.find(params[:id]) respond_to do |format| format.html format.json { render json: @user } format.xml { render xml: @user } end end 👉 Key Insight One controller action can serve multiple clients efficiently2. How Clients Choose the Format🔹 Methods:
HTTP Accept header
URL extension (.json, .xml)
🔹 Example:GET /users/1.json 👉 Key Insight The client—not the server—decides the response format3. The Serialization Pipeline🔹 Step 1: Data Preparation
Convert model → Ruby hash
🔹 Step 2: Data Transformation
Convert hash → JSON string
👉 Key Insight Serialization is a two-step process, not a single action4. as_json vs to_json🔹 as_json:
Returns a Ruby hash
Used for customization
🔹 to_json:
Converts to JSON string
🔹 Best practice:render json: @user 👉 Key Insight Let Rails handle conversion to avoid double encoding5. Why Use render Instead of Manual Conversion❌ Bad:render json: @user.to_json ✅ Good:render json: @user 👉 Key Insight Rails automatically calls serialization methods correctly6. Moving Logic from Controllers to Models🔹 Problem:
Controllers become cluttered
🔹 Solution:
Customize JSON in the model
def as_json(options = {}) super(only: [:id, :name]) end 👉 Key Insight Fat models + skinny controllers = clean architecture7. Filtering Data for Efficiency🔹 Options:
only → include specific fields
except → exclude fields
render json: @user, only: [:id, :email] 👉 Key Insight Send only what the client needs → better performance8. Including Associations🔹 Example:render json: @user, include: :posts 👉 Key Insight You can return related data in a single response9. Renaming and Customizing Fields🔹 Example:def as_json(options = {}) super.merge({ full_name: "#{first_name} #{last_name}" }) end 👉 Key Insight APIs should be client-friendly, not database-driven10. Adding Derived Data🔹 Examples:
Unix timestamps
Boolean flags
Computed values
def as_json(options = {}) super.merge({ created_at_unix: created_at.to_i, active: status == "active" }) end 👉 Key Insight APIs can provide ready-to-use data, not raw data11. Clean Architecture Strategy🔹 Controller:
Handles request/response
🔹 Model:
Handles data formatting
👉 Key Insight Separation of concerns improves maintainabilityKey Takeaways
Use respond_to for multi-format APIs
Serialization = prepare + transform
Prefer render json: over manual conversion
Move formatting logic into models
Customize responses for performance and clarity
Big PictureYou are building:👉 Flexible APIs for multiple clients 👉 Efficient data responses 👉 Clean, maintainable Rails architectureMental ModelRequest → controller action → choose format → model prepares data → Rails serializes → response sent