Versiones API elegantes en Rails

Question

Actualmente estoy implementando versiones para nuestra API REST en nuestra aplicación Rails. ¿Hay alguna manera de implementar esto, por lo que solo defines nuevas funcionalidades en las nuevas versiones? Digamos por ejemplo:

Tengo un controlador de usuario y un controlador de productos. Los productos se han mantenido igual entre V1 y V2, pero los usuarios han cambiado. Sería bueno si pudiésemos configurarlo de modo que si solicito el V2 de Productos, mi aplicación sepa que no existe y simplemente use la versión más reciente del controlador (en este caso, V1). Esto nos permitiría no crear un nuevo conjunto de controladores para cada versión; solo creamos nuevos controladores para la funcionalidad específica que ha cambiado.

A continuación se muestra un fragmento de nuestro Routes.rb, y no tengo idea de cómo abordar este problema. ¡Cualquier ayuda sería muy apreciada!

namespace :api do 
    scope module: :v1, constraints: ApiConstraints.new(version: 1) do 
     resources :users 
     resources :products 
    end 
    scope module: :v2, constraints: ApiConstraints.new(version: 2) do 
     resources :users 
    end 
end 

Answer 1

ya has mirado Grape ya?

Lo que he hecho con las API que he creado es que cuando algo cambia para todas ellas (como la autenticación) acabo de heredar todas de un controlador api versionado específico, como en Api::V1::BaseController y coloco el comportamiento común y controles allí.

Desde el cambio de la API generalmente también significó el cambio de las representaciones, utilizando una herramienta que genera las representaciones para su también es muy importante, hay muchas otras joyas que hay para esto como:

• RABL
• Roar
• Jbuilder

Answer 2

Esto es lo que Grape está diseñado para hacer.

Además, tiene la opción de montar su API en su archivo routes.rb o mapearlo en config.ru, evitando la pila de Rails y mejorando en gran medida el rendimiento de la API.

Answer 3

He utilizado la misma estrategia por algún tiempo y recientemente cambié de enfoque, y estoy de acuerdo que soy parcial porque también soy uno de los autores de nuestro nuevo enfoque con VersionCake.

Este enfoque consiste únicamente en versionar nuestras cargas o vistas, todas las vistas son el contrato entre el cliente y si hay un cambio en el contrato, entonces la versión debe cambiar. En VersionCake, que pueda versión de sus puntos de vista, así:

app/views/products/show.v1.rabl 
app/views/products/show.v2.rabl 
app/views/users/show.v1.rabl 

La función específica que es importante en base a su pregunta es que VersionCake se degradan con gracia a la última versión compatible. Dado el ejemplo anterior, un cliente que solicite users/1.json para la versión 2 recibirá la carga para users/show.v1.rabl.

Dicho esto, sería necesario adoptar un nuevo enfoque de control de versiones, por lo que podría no ser la mejor respuesta, pero creo que es una opción que vale la pena considerar.