Dove implementare la convalida dei dati URL in Node / Express?

Question

Dove implementare la convalida dei dati URL in Node / Express?

#1 da (2 voti)

2

Sto costruendo un'API RESTful usando Node / Express4 e finora ho avuto successo. Tuttavia, non sono sicuro di dove implementare la convalida dei dati degli URL - lo script del router potrebbe bloccare le richieste URI non valide o dovrebbe inviare al controller i dati non validi per inviare un errore?

L'URI previsto è come nel seguente esempio:

/api/:tagName/:postYear/:postMonth/:postDay

E dovrebbe restituirmi un array JSON di post in Anno / Mese / Giorno.

Quello che voglio è implementare un modo per impedire che una richiesta di data non valida venga inviata alla query del database, ad esempio

/api/:tagName/20170105

Dovrebbe restituire un errore.

Il mio dubbio è se sia più appropriato che il router convalidi l'anno nell'esempio (4 cifre, solo caratteri numerici) o se debba inviare "20170105" al controller e farlo analizzare l'URI e lanciare un errore di nuovo al cliente.

Esiste un modo consigliato o funziona ugualmente bene da un punto di vista strutturale?

web-development rest mvc

posta gchiconi 07.09.2017 - 15:27

fonte

1 risposta

Leggi altre domande sui tag web-development rest mvc

Come si suddivide il livello dell'interfaccia utente (MVC) in modo che più team possano lavorare su di esso? Verifica del token di accesso in ogni servizio di un'architettura di Microservice

score 2 · Accepted Answer

Non è sicuro che si tratti di una regola dura e veloce, ma generalmente la convalida è fatta il prima possibile. Perché sprecare altro tempo con valori non validi?

Alcune cose specifiche del nodo da considerare:

Stai generando codice di routing con Swagger o altri strumenti simili? In tal caso, la convalida dell'URL in Swagger è un ottimo meccanismo di applicazione del contratto.
Utilizzi già qualcosa come supertest per "eseguire" il tuo servizio come parte dei test unitari? Ciò rende la convalida a livello di richiesta molto più semplice dell'avvio di un'istanza di servizio per ogni test. In caso contrario, ha molto senso spingere la maggior parte della validazione e della logica al controller dove può essere più facilmente testato.

Valida a parte, se l'API richiede anno, mese e giorno, potresti prendere in considerazione l'utilizzo della modifica dell'endpoint per utilizzare la data come filtro come parametro del percorso ( /api/myTag/20170907 ) o come un parametro di query ( /api/myTag?date=20170907 ). Annidare molti parametri come nel tuo esempio non è proprio vero per il paradigma di identificazione delle risorse di REST, e potrebbe dimostrare sia una migliore UX che una più facile verifica. (Ma anche questo non è qualcosa che richiede il rispetto di un rigido insieme di regole).