Implementación de Métodos y Manejo de Excepciones en Rails API

Construye un API de Rails robusto paso a paso: implementa create y update en tu controlador, filtra parámetros con strong parameters y devuelve errores consistentes en JSON. Con una estructura clara y pruebas que pasan, ganarás confianza al escribir controladores mantenibles.

¿Cómo crear y actualizar posts en un controlador Rails?

Para que las pruebas pasen, se implementan las acciones create y update en el controlador. Se usan las versiones con signo de admiración (create! y update!) para que fallen cuando el modelo sea inválido y así poder manejar la excepción.

class PostsController < ApplicationController
  def create
    post = Post.create!(create_params)
    render json: post, status: :created
  end

  def update
    post = Post.find(params[:id])
    post.update!(update_params)
    render json: post, status: :ok
  end

  private

  def create_params
    params.require(:post).permit(:title, :content, :published, :user_id)
  end

  def update_params
    params.require(:post).permit(:title, :content, :published)
  end
end

• Usar create! y update! obliga a manejar errores de validación.
• Render en JSON con status adecuado: created en create y ok en update.
• Separar create_params y update_params evita modificar el user_id en updates.
• La ruta correcta es en plural: /posts.

¿Qué parámetros permitir con strong parameters?

• Requerir la clave :post con params.require(:post).
• En create: permitir title, content, published y temporalmente user_id.
• En update: permitir title, content y published; no permitir user_id.
• Esta separación prepara el terreno para autenticación futura.

¿Qué rutas y pruebas aseguran el comportamiento?

Tras implementar el controlador, las pruebas fallan por rutas faltantes. Se agregan las rutas create y update para que el API responda en los endpoints esperados.

# config/routes.rb
resources :posts, only: [:create, :update]

• Agregar solo las rutas necesarias reduce superficie de error.
• Ejecutar pruebas y revisar el primer fallo acelera el ciclo de feedback.
• Corrección de prueba: en creación, esperar que el objeto no sea nil, no que responda a empty.
• Con rutas y expectativa corregidas, las pruebas de creación y actualización pasan.

¿Cómo depurar fallos comunes en pruebas?

• Verificar que la URL sea plural: /posts.
• Confirmar que el ID llega en params para update.
• Ajustar expectativas del test a la naturaleza del objeto (no usar empty en modelos).

¿Cómo manejar excepciones en un API de Rails con rescue_from?

El uso de create! y update! dispara excepciones cuando el registro es inválido. Para responder correctamente y siempre en JSON, se agrega un exception handler con rescue_from.

class PostsController < ApplicationController
  rescue_from Exception do |e|
    # log.error e.message
    render json: { error: e.message }, status: 500
  end

  rescue_from ActiveRecord::RecordInvalid do |e|
    render json: { error: e.message }, status: 422
  end
end

• ActiveRecord::RecordInvalid se produce cuando el modelo no cumple validaciones.
• Responder con payload { error: mensaje } estandariza las respuestas de error.
• Usar 422 para datos inválidos y 500 para errores no controlados.
• El orden importa: el rescue_from declarado de último tiene más prioridad. Colocar primero la excepción genérica y después la específica.
• Buenas prácticas: registrar el error con log.error y contar con monitoreo en producción.

¿Por qué usar el signo de admiración en create/update?

• Obliga a que fallos de validación no pasen silenciosos.
• Facilita pruebas que esperan errores controlados.
• Permite centralizar el manejo con rescue_from y responder en JSON.

¿Tienes otra estrategia para estructurar los handlers o prefieres símbolos de estado en lugar de códigos? Comparte tu enfoque en los comentarios.