Un client dovrebbe verificare i parametri validi?

Le domande principali sono: da dove viene il valore e quanto è probabile che cambi intervallo consentito? Secondario: qual è il costo e le conseguenze dell'invio di una richiesta errata?

In generale un check nel client manifesta l'API. Forse in una versione futura l'API consente un conteggio maggiore. Se questo è limitato in troppi luoghi hai più difficoltà ad adottare questo.

Dall'altro lato ci sono domande di usabilità. Se il valore è inserito dall'utente e puoi dare un feedback immediato, l'usabilità è molto più alta di quando devi prima inviarlo a un server che deve poi elaborarlo. Tuttavia, se questo è un valore calcolato dalla tua app, dovresti controllare attentamente i tuoi algoritmi in quanto potrebbero trovare più bug.

In terzo luogo ci possono essere altri costi da richieste non valide. Ad esempio, l'API potrebbe essere un tasso limitato o un addebito per richiesta. Per alcuni servizi anche richieste non valide potrebbero portare a calcoli complessi e sprechi di risorse della CPU. Evitando richieste non valide, è possibile risparmiare denaro.

Controllare il valore sul client è una buona idea, perché se il valore è riconosciuto come errato sul lato client non stai sprecando larghezza di banda facendo un viaggio sul server che restituirebbe comunque un codice fallito.

Ma anche con il client che implementa la convalida, il server deve comunque includere la propria convalida dei dati passati e non fidarsi mai di un input non elaborato.

Se stavo scrivendo il client REST, mi aspetterei una "Richiesta errata HTTP 400" dal server. E se scrivessi codice java invocando una libreria sul lato client che alla fine mette le chiamate REST su un server, mi aspetterei un'eccezione IllegalArgument .

Non c'è nulla in questa domanda che sia specificamente pertinente per java, o per le API REST, (*) o per la programmazione lato client o per la programmazione lato server. Il fatto è che si sta programmando contro un'interfaccia. Un'interfaccia è due cose:

1. Un'interfaccia è un'emulazione .

Come astrazione, l'interfaccia dovrebbe preferibilmente nascondere tutti i dettagli specifici dell'implementazione dal chiamante. Per quanto riguarda la validazione dei parametri, questa è un'area grigia, perché per ogni parametro è necessario considerare se i suoi limiti sono ciò che sono dovuti alla natura dell'interfaccia o a causa delle peculiarità dell'implementazione. Ad esempio, se il server offre un mazzo di carte, un limite di 50 sarebbe una peculiarità dell'implementazione, poiché i mazzi di carte normalmente hanno 52 carte, o 54 se i jolly sono consentiti. Se il limite era 52, allora potreste dire che questa è un'interfaccia per un mazzo di carte senza jolly e considerare il limite come parte dell'interfaccia.

Quindi, per riassumere, se un limite può essere incluso nella descrizione agnostica dell'implementazione dell'interfaccia, allora validarlo con tutti i mezzi. In caso contrario, ignorarlo e lasciare che l'implementazione lo convalidi. Ma assicurati di leggere prima la prossima sezione.

2. Un'interfaccia è contratto .

Se dovessi lasciare che l'altra parte faccia quello che vuole, senza mai verificare se stanno rispettando la loro parte del contratto, ti stai preparando per essere sfruttato. La tua vita sarà dura.

Di fatto, la decenza comune impone di controllare tutto ciò che è possibile controllare ragionevolmente anche sulle chiamate in uscita, in modo da:

• assicurati di non violare mai il contratto dal tuo lato e

• sapere quando hai fatto qualcosa di sbagliato senza dover fare affidamento sull'altro lato facendo il loro lavoro correttamente e convalidando le tue chiamate.

_{(*) Questa brutta abitudine di dire "API" mentre in realtà significa "API REST" muore per una brutta morte? grazie!}

Controllare il valore e lanciare un'eccezione è un'implementazione di un sistema Fail Fast . Il suo valore dipende dalle ulteriori conseguenze dell'errore. Se accettare un valore errato può causare errori misteriosi in un secondo momento, è sicuramente più semplice correggerlo in caso di errore immediato.

Se esiste un'API, dovrebbe esserci una specifica per l'API. E tu speri che le specifiche siano per una ragionevole API. C'è il momento in cui si sviluppa il cliente rispetto alle specifiche e la lettera indica il momento in cui le persone utilizzano il client (e le specifiche potrebbero cambiare).

Durante lo sviluppo vorrai che il client si guasti in modo che gli sviluppatori correggano il loro codice.

Dopo lo sviluppo, o la specifica rimane invariata, o l'API è progettata in modo che le specifiche possano cambiare e il client possa essere eseguito invariato.

Poiché il server ha la conoscenza definitiva di un limite per il conteggio, ad esempio (e conosce meglio del client che è solo una supposizione, e migliore della specifica, perché la specifica è solo una specifica, ma il codice del server è la verità ), preferirei un'interfaccia in cui il client può chiedere quello che vuole, e ottiene tutto ciò che il server è disposto a dargli, e può capire facilmente come ottenere tutto ciò che non è Là.

In questa situazione, ad esempio, il cliente potrebbe chiedere n elementi. Il limite del server potrebbe essere m articoli, e potrebbero esserci k elementi effettivamente presenti. Il numero di elementi restituiti potrebbe quindi essere min (n, m, k) e il numero "accettato" di elementi sarebbe min (n, m). Il server può restituire entrambi i numeri insieme ai risultati della richiesta, in modo che qualsiasi situazione possa essere gestita. (E ovviamente c'è un parametro "start" mancante, quindi le chiamate consecutive possono gestire tutti i dati).

Pensaci: se il client richiede 52 elementi e di conseguenza viene generata un'eccezione, che cosa farebbe allora il client?