Comunicazione con API di terze parti

Naviga le tue risposte
2

Sto lavorando su un'App che fondamentalmente comunica con un'API di terze parti, non ha back-end. Il front-end sarà una SPA. Ecco lo scenario generale:

  1. L'API esterna richiede l'ID dell'utente corrente per rispondere alla query richiesta.
  2. Il mio server inizialmente ha le informazioni dell'utente che può utilizzare per interrogare l'API e ottenere il risultato desiderato.
  3. In base alla risposta iniziale, l'utente inserisce ulteriori dettagli e richiede di nuovo l'API per la risposta finale.

Possibili soluzioni nella mia mente:

Soluzione 1 (con sovraccarico di richieste aggiuntive):

  1. Alla prima richiesta servi la home page all'utente, quindi lascia che sia front-end invia una richiesta (con le informazioni utente registrate) al mio server per ottenere i dati iniziali dall'API esterna.
  2. Ora, il mio server richiede l'API esterna, ottiene la risposta e invia tale risposta al client.
  3. Il cliente riceve la risposta, effettua un'altra richiesta in base alla risposta.
  4. Ripeti il passaggio 2 con i dati aggiuntivi.

Soluzione 2:

  1. Poiché il server ha già le informazioni utente (utilizzando oauth2), prima di richiedere l'API, quindi eseguire il rendering della pagina di destinazione con la risposta caricata nella pagina come dati JSON globali statici, lasciare che il codice front-end esegua la query dati statici e usalo costruisci la prossima richiesta.
  2. Ora, abbiamo lo stesso scenario del passaggio 2 menzionato sopra.

PS: l'API comunica tramite il protocollo SOAP e mantiene una sessione utilizzando oauth2.

Domanda: Quale scenario è migliore rispetto alla gestione degli errori e alla disponibilità? Come devo gestire il caso quando l'API non funziona?

    
posta CodeYogi 01.02.2016 - 16:13
fonte

1 risposta

1

Quindi, se ho capito bene, la differenza tra le 2 soluzioni è in realtà solo nel servire la prima pagina se l'API esterna è inattiva:

  • soluzione 1 sta scontando una pagina generica (quindi potenzialmente inutile)
  • soluzione 2 sta servendo una pagina personalizzata (ma con informazioni potenzialmente memorizzate nella cache)

Entrambe le soluzioni falliranno le richieste successive se l'API esterna rimane inattiva, quindi in realtà non c'è una differenza significativa tra la gestione degli errori e la prospettiva di disponibilità.

Personalmente non progetterei un'app con una dipendenza così totale dall'API esterna, potrei disaccoppiare un po 'le richieste alla mia app dalle richieste all'API esterna, nel senso che fornirei sempre una risposta , anche se ciò significa semplicemente informare l'utente dello stato di servizio inadeguato dell'API esterna.

Qualcosa in questo senso (in cui le attività di lunga durata sarebbero i tuoi accessi all'API esterna): link

Chiarimento: considero gli accessi API esterni come di lunga durata perché non hai il controllo sul tempo necessario per ottenere una risposta (se ne hai anche una) in modo che l'app possa elaborarla e rispondere al client originale richiesta. Se l'intera operazione richiede più di 60 secondi (il limite di scadenza della richiesta GAE) l'app verrà uccisa.

potresti mantenere le chiamate sincrone all'API esterna come desiderato (la "modalità normale" dell'app, quando l'API esterna risponde in modo tempestivo), ma con un timeout di sicurezza che consente l'app per sbloccare, ricorrere alla "modalità offline" che ho descritto in Q & A, forse cambia lo stato del servizio di registrazione e rispondere ancora alla richiesta del cliente di conseguenza, tutto entro gli anni '60.

    
risposta data 02.02.2016 - 21:43
fonte

Leggi altre domande sui tag

Come evitare di avere nidificato in classe Possibile ESSERE con meccanismo di pausa