elegante delle versioni API in Rails

Question

Al momento sto attuazione delle versioni per la nostra API REST nella nostra applicazione Rails. C'è un modo in cui questo può essere implementato in modo da definire solo nuove funzionalità nelle nuove versioni? Diciamo per esempio:

Ho un regolatore di utenti e un controller prodotti. I prodotti sono rimasti gli stessi tra V1 e V2, ma gli utenti sono cambiati. Sarebbe bello se potessimo configurarlo in modo che se chiedo V2 di Prodotti, la mia applicazione sa che non esiste e utilizza semplicemente la versione più recente del controller (in questo caso, V1). Ciò consentirebbe a noi di non creare un nuovo set di controller per ogni versione; creeremmo solo nuovi controller per la funzionalità specifica che è cambiata.

Di seguito è riportato un frammento della nostra routes.rb, e devo ammettere che non ho idea di come affrontare questo problema. Qualsiasi aiuto sarebbe molto apprezzato!

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

Hai già guardato allo Grape?

Quello che ho fatto rispetto all'API che ho creato è, quando qualcosa cambia per tutti loro (come l'autenticazione), ma li faccio ereditare tutti da uno specifico controller API a versione, come in Api::V1::BaseController e posizionare il comportamento comune e controlli in là.

Dal cambiare l'API di solito significava anche la modifica delle rappresentazioni, utilizzando uno strumento che genera le rappresentazioni per la vostra è anche molto importante, ci sono molte gemme là fuori per questo come:

• RABL
• Roar
• Jbuilder

Answer 2

Questo è ciò che Grape è stato progettato per fare.

Inoltre, è possibile montare l'API nel file routes.rb o mapparla in config.ru, scavalcando lo stack Rails e migliorando notevolmente le prestazioni dell'API.

Answer 3

Ho usato la stessa strategia per un po 'di tempo e di recente ho cambiato approccio, e devo ammettere che sono di parte perché sono anche uno degli autori del nostro nuovo approccio con VersionCake.

Questo approccio è quello di versione solo i nostri carichi utili o viste, dopotutto viste sono il contratto tra il cliente e se v'è un cambiamento del contratto di rottura, quindi la versione deve cambiare. In VersionCake, è possibile versione vostri punti di vista in questo modo:

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

La caratteristica specifica che è importante in base alla tua domanda è che VersionCake sarà con grazia degrada con l'ultima versione supportata. Considerato l'esempio precedente, un client che richiede users/1.json per la versione 2 riceverà il payload per users/show.v1.rabl.

Tutto ciò detto, richiederebbe l'adozione di un nuovo approccio di versioning, quindi potrebbe non essere la risposta migliore, ma penso che sia un'opzione che vale la pena considerare.