Fino a che punto devo convalidare l'input dell'utente nella mia API creata?

1

Ho qualcosa qui che mi impallidisce un po '.

Diciamo che mi scrivo questa API (in TS), controlla alcune di queste proprietà:

export class MyAPI{
        propertyThatShouldContainSuffix:Array<string>; // like .jpg or .mp3 
        somethingElses:Array<SomethingElse>; //instances of some class
        enumProperty:SomeEnum; // enum SomeEnum{a,b,c,d}
        constructor(object){
           /*
             this object is input by the API consumer,
             and its properties will be assigned to the new fields of
             the new instance
                              */
        }
     }

Esempio di utilizzo valido:

var myApi = new MyAPI({
   propertyThatShouldContainSuffix : ["img.jpg","video.mp4" ...],
   somethingElses : [new SomethingElse(/*yada yada*/),new SomethingElse(/* whateverrr*/) ...],
   enumProperty:2
});

Input che potrebbe causare problemi:

var myApi = new MyAPI({
       propertyThatShouldContainSuffix : ["img","video",5 ...],
       somethingElses : [new SomethingElse(/*yada yada*/),new SomethingTotallyElse(/* whateverrr*/) ...],
       enumProperty:6
    });

Come puoi vedere, la prima proprietà è una serie di stringhe che devono avere un suffisso, come un'immagine, che dovrebbe essere .jpg o .png o altro. C'è una serie di oggetti che dovrebbero contenere alcuni campi, e infine un campo enum, diciamo che va da 0 a 3.

Ora funziona tutto bene e roba quando si inseriscono i valori previsti (ad esempio, tutte le stringhe nel primo array hanno il suffisso giusto e così via).

Ma poi ho pensato che avrei dovuto gestire input sbagliati, come un utente che invierà tutti i suoi nomi di immagine senza alcun suffisso, o mi darà un "9" come input per l'enum, invierò oggetti invece di matrici, e così on.

MA! ed ecco il problema: quanto lontano dovrei andare con questo? dovrei controllare che ogni proprietà sia corretta (ad esempio, ciò che si suppone essere un array è in realtà un array, che tutti i "supposti per essere suffissi" sono suffissi, che tutti i "somethingelses" contengono tutti i campi corretti?

Perché se lo faccio, questo è un casino di overhead su ogni creazione di un'istanza di oggetto MyAPI.

O dovrei fare qualcosa di veramente semplice come controllare se non ha sbagliato a scrivere un campo nell'oggetto (quindi esponendo gli utenti indifesi ai pericoli di "ma perché non funziona? stupida stupida API!")?

O qualsiasi cosa tra?

    
posta Or Yaniv 05.02.2016 - 15:10
fonte

3 risposte

1

Dovresti fornire un'API con la documentazione. Nella tua documentazione dovresti documentare quali input sono gestiti in modo univoco, quali input errati verranno rilevati e come risponderai a loro - e quali input errati non verranno rilevati. E la tua implementazione dovrebbe seguire quella documentazione.

La tua API può essere scritta con l'atteggiamento "chiamarla nel modo sbagliato è un errore di programmazione, quindi devi correggere quell'errore". Va perfettamente bene Quindi quando dico "quali input errati si riveleranno e come risponderai a loro" - dicendo che sicuramente ti capiterà di andare in crash è assolutamente bene con me. E se dici che non controlli l'input non corretto, significa che passare quell'input errato è un errore di programmazione errato che potrebbe portare a errori di difficile individuazione. In tal caso, beh, gli utenti della tua biblioteca devono leggere la documentazione.

    
risposta data 05.02.2016 - 23:51
fonte
1

Controllare il suffisso del file sembra facile, ma alla fine inutile. Un file chiamato foo.bar potrebbe essere un file jpeg valido. Un file chiamato reallyIsA.jpg potrebbe essere un virus sgradevole.

Ricorda quando alcuni firewall aziendali ti impediscono di inviare tramite email file .exe o .zip e tutti hanno appena modificato le estensioni?

IMO, la tua API dovrebbe specificare "un file in uno di questi formati di immagine: (metti la lista qui).". Quindi specifica l'eccezione o rispondi se non è uno di quelli.

    
risposta data 06.02.2016 - 00:47
fonte
0

In questo esempio e in molti altri esempi del mondo reale, il sovraccarico della convalida sarà trascurabile rispetto al lavoro che la tua API dovrebbe svolgere. Per i principianti potresti voler creare una classe MediaFile che incapsula l'input della tua API. È quindi possibile eseguire tutte le convalide nel costruttore della classe del file multimediale. MediaFile potrebbe essere astratto e potresti avere discendenti JpgFile e Mp3File. Oppure potresti avere una classe MediaFile generica che prende un percorso di file e capisce il tipo del file. Se la classe MediaFile rileva un problema con il file specificato, è possibile farlo esplodere con un messaggio chiaro. Ciò eliminerebbe le cose e la tua API sarebbe sicura di ricevere oggetti MediaFile validi e completamente inizializzati. Il controllo di null sarebbe sufficiente.

Ciò che non sembra giusto per te ora è che stai spingendo troppe responsabilità non fondamentali nella tua API. Questi possono essere gestiti in anticipo, esterni all'API.

    
risposta data 05.02.2016 - 22:29
fonte