Come lavorare con / attorno a un'API che non restituisce errori?

Question

Come lavorare con / attorno a un'API che non restituisce errori?

#1 da (4 voti)
#2 da (4 voti)

7

Attualmente sto lavorando a un progetto che richiede il recupero dei dati da un'API chiusa di terze parti (su SOAP).

Attualmente mi trovo in una situazione in cui devo eseguire argomentazioni e convalida dei dati all'interno del nostro codice applicazione, poiché l'API di terze parti citata non restituisce nulla relativo agli errori. Esempi:

Richiedi qualcosa con un argomento di query non valido (ad es. 'helloworld' invece di 12345 ): l'API restituisce null , quindi non mi dice cosa ha effettivamente rotto la richiesta.
Richiesta senza argomenti di query, mentre l'API prevede alcuni argomenti: l'API restituisce null , quindi sono di nuovo all'oscuro su cosa sta succedendo.
L'API può restituire una raccolta di dati o una singola porzione di dati. Come gestisce "nessun dato trovato": restituisce null come in tutti quei casi di errore. In questo modo non so se effettivamente non c'è nulla da trovare o se l'API si è rotta di nuovo.

Ho provato varie cose e mappato cosa funziona e cosa no. Ho alcune richieste di richieste di esempio da parte del provider dell'API, quindi almeno so quali sono le risposte richieste di successo .

Ci sono dei buoni modi per gestire situazioni come queste quando non posso semplicemente chiedere al provider dell'API di implementare la corretta gestione degli errori o approcci simili?

Devo continuare a sperimentare e perdere tempo mentre implemento la logica di convalida all'interno della nostra logica di applicazione (che dovrebbe quindi essere astratta nel caso in cui l'API stessa cambi o venga scaricata)?

(L'ho postato ai programmatori SE anziché SO perché non si tratta di dettagli specifici sull'implementazione tecnica, ma di un modo per gestire il problema in generale.)

error-handling api validation

posta ojrask 06.05.2016 - 14:50

fonte

2 risposte

4

Per questa chiamata di servizio, si potrebbe voler implementare la registrazione dettagliata.

Presumo che ci sia una diversa gestione degli errori in atto. Quando si verifica un errore o viene restituito un valore nullo, registrare tutto nella richiesta e nella risposta. In genere questo tipo di informazioni verrebbe inserito in un registro di debug, ma in questo caso lo promuoverei per la registrazione normale. Quindi, puoi gestire nuovi casi o condizioni man mano che si presentano.

risposta data 06.05.2016 - 15:58

fonte

Leggi altre domande sui tag error-handling api validation

in linguaggio dinamico come javascript come fai a sapere qual è l'argomento? Refactoring di tre classi molto simili usando l'ereditarietà?

score 4 · Accepted Answer

Ho implementato e utilizzato un'API "permissiva" simile a ciò che stai descrivendo. Ma era indulgente solo per le operazioni di tipo read. E la ragione era piuttosto semplice: l'API sottostante (MySQL) era indulgente.

Se ti colleghi ad un database MySQL, ad esempio, potresti pensare che l'unico modo "valido" per selezionare un record per il suo INT PK è di dargli un INT:

mysql> select * from users where user_id=123;
Empty set (0.01 sec)

E se ottieni un set vuoto, penserai "Oh, non ci sono utenti con un ID di 123". Ma puoi anche dare a MySQL una stringa legittima:

mysql> select * from users where user_id='Uncle Bob';
Empty set (0.01 sec)

E a MySQL non interessa. Dice solo: "Vediamo ... oh si! Nessuno di questi interi corrisponde a 'Uncle Bob' ... quindi, questo è un set vuoto, figlio".

La mia API non ha ricevuto un errore di convalida dall'API sottostante , quindi non ho mai visto la necessità di "fabbricarne" uno. E, in un certo senso, ha senso: se stai interrogando per dati che corrispondono a identificatori malformati o non validi, il set risultante è solo vuoto

Per operazioni di lettura , se vuoi dare suggerimenti utili all'utente, dipende da te. D'altra parte, se l'utente non sa già cosa va nel campo ID, dare loro suggerimenti è potenzialmente spreco di energie.

Per le operazioni di scrittura , un'API che ignora le richieste non valide e non riesce a lamentarsi è probabilmente "infranta". Ma, se questo è il caso, potrebbe lavorare con l'API "interrotta" seguendo ogni PUT con un GET per verificare le modifiche. Non è l'ideale, ovviamente; ma, dovrebbe risolvere il problema.