Se stai dando un flusso di controllo all'API, la risposta è aspettare che l'inferno si congeli, o l'utente preme ctrl-alt-del. Se lo chiami in modo asincrono, la strategia tipica è il timeout.

Se l'API genera un'eccezione, facile: ripulire, registrare e visualizzare l'errore.

Qualunque cosa tu faccia, non fallire in silenzio. Odio il debugging di cose che falliscono silenziosamente.

Nessuna risposta?

Se l'API ritorna ma non ti dà nulla, vale a dire nullo o nullo, beh ciò significa che qualsiasi API l'ha documentato. Null è sovraccarico per significare molte cose. È un buco nel sistema di battitura. Sir Hoare l'ha definito un errore da un miliardo di dollari.

Quando chiedi qualcosa, fai una domanda, cioè fai una domanda. Ogni domanda ha una premessa. Qualcosa assume per vero. Quando questa ipotesi è sbagliata, rispondiamo con qualcosa di diverso da quello che ci si aspettava. Potremmo essere in un sistema che presuppone che possa chiedere l'altezza di qualsiasi cosa e ritrovarci a modellare una canzone. Quando ti viene chiesto l'altezza di una canzone, come puoi rispondere? Crea qualche sciocchezza di ampiezza e attaccalo in un oggetto di altezza? Di solito rispondiamo con un'eccezione, un codice di errore, un NaN, o in alcuni casi tristi, con un nulla. Ogni API avrà già preso questa decisione. Qualunque cosa abbiano fatto, se viola le aspettative della domanda solo per favore, non fallire in silenzio. Dare un'idea di cosa potrebbe essere sbagliato. Anche 404 è meglio di una pagina vuota.

Se non puoi fare affidamento sull'API di terze parti per darti una risposta (e stai accedendo in modo sincrono) puoi impostare un timeout. Accederei all'API di terze parti su un thread separato (o anche su un processo) e attendo la risposta con un set di timeout. Se il timeout scade, basta andare avanti.

Inoltre, ho avuto un problema molto simile qualche tempo fa. Sentiti libero di dargli un'occhiata:

Evitare blocchi quando si chiama un'API.

Nel mio caso, l'API era una DLL nativa di Windows di terze parti scritta in C ++. Non importa che la tua API non sia una DLL Windows nativa, puoi comunque utilizzare alcune delle strategie suggerite dalle persone come risposte. Spero che tutto funzioni per te.

Non penso che ci sia una risposta ben definita. Dipende naturalmente. Se fossi in te, penserei a quale sarebbe l'esperienza utente ideale quando questo accadrà. Quindi fai tutto quello che serve nella tua applicazione per farlo accadere.

Potresti semplicemente lanciare un errore e dire all'utente di riprovare più tardi. O se si tratta di un problema che si verifica sporadicamente, riprova nuovamente la richiesta per loro. Assicurati solo di far loro sapere che stai lavorando per ottenere i dati per loro e che richiede più tempo del solito. Qualunque cosa tu faccia, non fuorviare l'uso e non lasciare uno spinner sullo schermo lì indefinitamente.

Quando chiami un'API tramite https, puoi ottenere le seguenti risposte: Internet non disponibile. Impossibile connettersi al server. https non è riuscito a negoziare (dopo aver raggiunto il server). Una risposta senza senso quando usi http in uno Starbucks. Il server ti dice che l'API è attualmente inattivo. L'API ti dice che non sta funzionando in questo momento. L'API fornisce uno dei molti codici di stato che indicano che qualcosa è andato storto. L'API ti fornisce un codice di stato che indica che ha una risposta, ma la risposta sembra sbagliata. L'API ti fornisce un codice di stato che indica che ha una risposta e la risposta sembra corretta.

Alcune cose indicano errori nel codice, quindi li correggi. Alcune cose indicano errori nel codice API, quindi chiedi a qualcuno di risolverli.

A parte questo, se non ottieni una buona risposta, devi riflettere su quale sia la cosa più utile da dire all'utente. Se c'è qualcosa che l'utente può fare per risolvere il problema (che può essere "riprova più tardi" o "chiama l'help desk" o "attiva la rete"), diglielo. Se non c'è nulla che possono fare, fai tutto ciò che è più utile.