È necessario creare un endpoint API separato per le app mobili per accedere a un'app Web di Rails?

Question

Ho un'applicazione web implementata in Ruby on Rails 4, ho bisogno di un'app nativa per Android, sono davvero nuova per lo sviluppo mobile.

Sono un po 'confuso su come dovrebbe essere l'architettura della mobile web in questo caso. Ho fatto qualche ricerca online, sembra che ci siano alcuni modi per farlo, ma ho ancora alcune domande per le quali non sono stato in grado di trovare risposte. Grazie in anticipo per tutti i suggerimenti.

1) ho davvero bisogno di un'API separata per l'app mobile? Quali sono i problemi nell'utilizzo dei controller esistenti dell'app di Rails con respond_toformat.json?

2) Ho visto alcuni esempi online che suggeriscono di utilizzare uno spazio dei nomi API separato nell'app Rails per servire le richieste mobili, ad esempio class Api::ApiController < ActionController::Base per il nuovo controller, quindi aggiungere namespace :api do in routes.rb. Con questo approccio, non implica che dovrò duplicare un bel po 'delle funzionalità del mio controller in questo nuovo spazio dei nomi solo per i dispositivi mobili?

3) Per quanto riguarda l'autenticazione, molti esempi suggeriscono l'utilizzo dell'autenticazione con token, la struttura di gestione delle sessioni di Rails incorporata non è sufficiente per le app mobili? o perché i cookie di sessione funzionano in modo completamente diverso in un'app mobile?

Apprezzo il tuo tempo.

Answer 1

Non è necessario, ma è, come hai detto, considerato una buona pratica.

1 + 2) Avere gli stessi controller con respond_to/respond_with logic è una bella idea a prima vista. Tuttavia, dalla mia esperienza, posso dire, arriva sempre un giorno in cui il codice API inizia a differire con il codice client HTML. Il client mobile potrebbe avere un'interfaccia utente diversa ed è naturale che preveda di consumare i tuoi dati in un altro modo come fa il tuo client web. Il web client è specializzato in un caso d'uso in cui un'API dovrebbe essere più generica consentendo molteplici modi di consumo.

Il secondo problema che si presenterà è il fatto che non è possibile fare affidamento sugli utenti mobili per avere sempre l'ultima versione dell'app dove è possibile con una webapp. Pertanto, per l'app HTML è possibile introdurre facilmente modifiche non compatibili perché si sta consegnando un client appropriato all'interno del quale l'API mobile che infrange l'API è almeno preoccupante. Forse, vorrai mantenere una retrocompatibilità che renderà brutti i tuoi controller per tutti gli usi. E senza un vero namespace api/v1 non puoi nemmeno avere due versioni API diverse allo stesso tempo.

È possibile evitare la duplicazione della logica mantenendo i controller molto scarni e spostare la logica in modelli (anche gli oggetti di servizio sono modelli, non solo i record attivi).

3) Probabilmente, la tua lib di HTTP mobile avrà un'adeguata gestione automatica dei cookie. Avere l'autenticazione basata su token è solo di nuovo una best practice. Se è solo un token vs session_id all'interno del cookie, non ci sarà molto successo. Posso solo pensare che sarà automaticamente sicuro contro l'attacco CSRF e puoi disabilitare questa protezione interamente per l'API perché gli utenti del tuo sito web non potranno utilizzare l'API, semplicemente accedendo al sito (un ulteriore vantaggio forse) . Con l'autenticazione basata sulla sessione dovrai generare un token CSRF alla prima richiesta API e impostarlo nel cookie X-CSRF-Token.

Il grande vantaggio dell'autenticazione basata su token è che è estendibile a più sicurezza, come l'introduzione di token di scadenza, token HMAC ecc., In cui l'autenticazione di sessione non lo è. Vedi Using Sessions vs Tokens for API authentication

Vorrei anche invitarvi a guardare json:api. Proviene dai creatori di ember.js, che hanno pensato di prendere decisioni minime da prendere quando costruiscono le API. Un'altra cosa interessante è una gemma active_model_serializers. Un'introduzione ad esso è data entro Rails: The Next Five Years by Yehuda Katz