Un client dovrebbe mai testare la risposta del server durante il runtime?

2

Sto scrivendo un'applicazione client che riceve una risposta JSON da un server. In passato mi sono imbattuto in situazioni in cui uno sviluppatore sul lato server modifica la risposta JSON in un modo che causa l'arresto anomalo dell'applicazione client. Un esempio di ciò è quando il client si aspetta che un campo JSON o subobject sia sempre presente, ma una modifica sul lato server fa sì che il JSON si discosti da ciò che si prevede possa restituire un valore nullo quando null non dovrebbe mai essere una possibile risposta.

Sembra che il lato server possa sempre disporre di test unitari che assicurino che la risposta JSON soddisfi il contratto, ma è suscettibile di errore umano se uno sviluppatore decide di riscrivere un test o semplicemente commette un errore nel test o fraintende un requisito. Il lato client può verificare che la risposta JSON sia valida, ma ciò dovrebbe essere necessario in fase di esecuzione e se il server sta scrivendo test appropriati, il doppio controllo della risposta del server da parte del client non sarebbe necessario.

Esiste un processo consigliato per garantire che il contratto (formato di risposta JSON) tra client e server non venga danneggiato?

    
posta neonDion 20.01.2016 - 02:24
fonte

2 risposte

7

Sì, dovresti convalidare ciò che ottieni, ma devi anche essere un lettore tollerante:

link

Martin Fowler afferma che:

My recommendation is to be as tolerant as possible when reading data from a service. If you're consuming an XML file, then only take the elements you need, ignore anything you don't. Furthermore make the minimum assumptions about the structure of the XML you're consuming.

Che, per la mia esperienza è un buon modo per essere resiliente (tollerante) ai cambiamenti. Inoltre, se la modifica è troppo grande per essere tollerante, dovresti prendere in considerazione alcune strategie per il controllo della versione dell'API:

  1. link
  2. link

Da un punto di vista più pratico, puoi anche scrivere alcuni test / contratti sulla tua API in modo da poter controllare continuamente i contratti:

  1. link (vedi i collegamenti alla fine della pagina)
  2. link
risposta data 20.01.2016 - 05:07
fonte
4

Perché mai, vero? Una buona regola empirica è di supporre che tutti gli input siano malvagi fino a prova contraria. Assumere ciecamente che il tuo contributo sia valido è un buon modo per svegliare database vuoti e log degli errori in eccesso. Solo perché quell'input proviene da un (presumibilmente competente) server di un collega non significa che dovrebbe ottenere un pass gratuito da te.

Per lo meno, si desidera che venga registrato un errore diverso per problemi relativi a client e server. Se il proprietario del server modifica la risposta senza preavviso, si desidera essere in grado di determinare il più rapidamente possibile la fonte dell'errore. Oltre a coprire te stesso verso la gestione, aiuta a essere in grado di dire a colpo d'occhio l'area generale di un problema quando l'applicazione smette di funzionare.

    
risposta data 20.01.2016 - 04:12
fonte

Leggi altre domande sui tag