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.