Disaccoppiare server e client utilizzando l'API REST

6

Stavo pensando a come disaccoppiare completamente un'applicazione web in un lato server e un componente lato client. Voglio disaccoppiare l'app nella misura in cui posso ospitare entrambi i componenti su server separati.

Quindi, ad esempio, avrei:

  1. Server 1 (Server API): un componente lato server in esecuzione su Django su qualcosa come Heroku o EC2.
  2. Server 2 (server statico): un componente lato client in esecuzione su AngularJS su un server statico come S3 o CloudFront.

La comunicazione tra questi componenti avverrà utilizzando un'API JSON REST.

Domande:

  1. Questo approccio è comune? consiglia?

    Does a company like Facebook or Twitter mostly utilise the same API for the webapp as it does for its mobile apps or its open API?

  2. È una buona idea usare oAuth2 per il processo di login?

    So the user is redirected to a login page on Server 1 (this is the only page on Server 1) and then redirected back to Server 2 with a token if authentication succeeds. Is this the best approach? It seems like I am kinda "breaking the flow" if I do this. Is this normal?

La motivazione per questo è per me essere in grado di utilizzare la stessa API per i miei clienti Web, iOS e Android.

Grazie!

    
posta nknj 11.03.2014 - 19:40
fonte

2 risposte

6

JSON / HTTP è un ottimo meccanismo di disaccoppiamento, e proporrò un paio di suggerimenti che lo renderanno ancora più sciolto.

La rapida adozione da parte del settore delle interfacce JSON / HTTP parla davvero bene di come le persone vedono l'utilità di quel modello.

  • Applica una regola MUST IGNORE.

Cioè, quando si analizza JSON (client o server), l'app DEVE IGNORARE tutti i campi che non riconosce.

XML è andato nell'idea che l'app DEVE CAPIRE A ogni campo, altrimenti il documento non era valido. Ma questo ha creato problemi con il controllo delle versioni, perché con quasi tutte le modifiche, i client dovevano eseguire l'aggiornamento ogni volta che il server veniva eseguito. Anche l'aggiunta di un campo informativo ha infranto le specifiche. Con MUST IGNORE, il server può aggiungere nuovi campi in qualsiasi momento e fintanto che non rimuove o modifica il significato di altri campi (vedi sotto). I clienti esistenti possono semplicemente ignorare i nuovi campi. Piuttosto, DEVONO IGNORARE i nuovi campi.

Una ricerca su DEVE IGNORARE e DEVE CAPIRE rivelerà molti buoni articoli che ne parlano.

  • Riduci al minimo le interruzioni di modifiche.

Un "cambio di rottura" è una modifica che interromperà i client esistenti. Cioè, rimuovendo un campo che usano i client. O cambiando il significato di un campo (cioè cambiando un campo di importo da dollari a Yen). Cioè, qualcosa che invalida le ipotesi di un cliente sui dati che sta attualmente utilizzando.

Con un cambiamento radicale, ogni cliente deve apportare una modifica per supportare la nuova semantica o smettere di fare affidamento sui campi mancanti. Non farlo se non è necessario.

Il prossimo passo logico diventa un po 'controverso, ma all'estremo della tua mente mai fai una svolta. Cioè, avere piena retrocompatibilità per ogni versione. Questo può essere o non essere realistico, e potrebbe richiedere il trasporto del bagaglio dalle prime versioni, ma risparmierà molto churn per i clienti.

  • OAuth 2 è davvero una buona scommessa per un protocollo di sicurezza standardizzato e ben congegnato. Potresti sederti e progettare qualcosa di più semplice, a seconda di quali compromessi sono OK. Ma OAuth è un buon protocollo aggiornato che ha subito anni di controllo del settore, quindi hanno avuto un sacco di tempo per elaborare i nodi. E le librerie standard sono prontamente disponibili per client e server. Ho usato un plugin OAuth per DJango per un progetto e ha funzionato molto bene.

  • A causa dell'ubiquità dei parser JSON, il mantenimento di un'API singola indipendentemente dal client renderà la vita molto più semplice. A volte non funziona - a volte un client può solo capire XML o qualche protocollo proprietario, ma iniziare con semplici e amp; l'aggiunta di complessità semplifica la vita.

risposta data 11.03.2014 - 21:53
fonte
3

Questo è molto comune e aiuta quando si progetta un'app mobile. Poiché la tua applicazione sarà già "orientata alle risorse" anziché essere focalizzata sulla generazione di dati con il livello html / visivo allegato.

Raccomando link per il lato Django, ho contribuito e lo uso anche quotidianamente. Aiuta a fornire un sacco di elementi costitutivi su Django che rendono il disaccoppiamento facile e potente.

Per quanto riguarda l'oAuth, puoi, non devi. Se controlli questo sito, mostra anche come configurare oAuth con l'API. Si può facilmente usare l'autenticazione Username / Password come per default. Basta che l'app angolare invii il nome utente / password combo all'endpoint, che risponderà con un "token". Finché l'app è ospitata utilizzando il buon TLS (), il token è sicuro. Puoi facilmente aggiungere un metodo per aggiornare i token per maggiore sicurezza.

    
risposta data 11.03.2014 - 20:10
fonte

Leggi altre domande sui tag