Fin dalla sua introduzione nelle funzionalità di Instant Developer Foundation, la possibilità di realizzare rapidamente Web API è stata una delle più apprezzate.
Ma, si sa, il fatto che sia facile ottenere un risultato non significa che ci si possa permettere di prendere sotto gamba un’implementazione. Il problema imprevisto è sempre dietro l’angolo e, per quanto riguarda le Web API, ci sono 3 aspetti da non sottovalutare mai:
- la messa in sicurezza;
- la limitazione dei risultati;
- la stabilità.
Il primo errore da evitare è relativo alla messa in sicurezza dell’applicazione. Attivare le Web API significa avere un punto di accesso all’applicazione che permette di effettuare qualsiasi tipo di operazione: lettura, modifica, cancellazione. Non è facile scoprire l’interfaccia di una Web API senza avere il codice a disposizione ma, se l’interfaccia diventasse nota per qualche motivo, allora sarebbe possibile fare danni davvero enormi.
Mettere in sicurezza le Web API è semplice e basta utilizzare lo stesso metodo usato da tante API di uso comune: l’header di autenticazione. È sufficiente fare in modo che il chiamante debba aggiungere un header di autenticazione alla chiamata e leggerlo nell’evento onWebAPI. Nel codice di esempio qui sotto ho globalizzato l’evento per praticità, controllando sempre una chiave fissa (praticamente una API key), ma questa stessa tecnica è utilizzabile anche per implementare controlli diversi per utente, classe, permesso, eccetera.
Il secondo errore da evitare è relativo alla limitazione dei risultati ottenibili tramite Web API. Il comportamento di default è non porre vincoli al numero di record restituiti. Questo significa che potrebbe essere possibile causare query di grandi dimensioni semplicemente sbagliando la chiamata GET inviata. Questo è troppo rischioso.
Per risolvere questo problema è sufficiente gestire l’evento onGlobalBeforeLoadCollection e impostare Collection.maxRows = <numero di record limitato>.
In questo esempio ho utilizzato l’evento GlobalDocumentWebAPI per impostare a 50 il numero di record da restituire. Lo imposto sul documento che ha scatenato l’evento tramite una setTag().
Lo rileggo poi nell’evento BeforeLoadCollection con getTag() e lo imposto come detto. Regolate voi il numero massimo di record che volete far restituire alle Web API a seconda della classe e della funzionalità che state implementando.
Ora abbiamo delle Web API sicure e che non rischiano di occupare tutte le risorse del server. Ma c’è un ultimo errore comune da evitare: romperle.
Il terzo errore da evitare è infatti relativo alla stabilità dell’interfaccia. Con Instant Developer Foundation è semplicissimo modificare il progetto anche nelle sue fasi più avanzate, ma se si è distribuito l’accesso alle Web API, ci sono alcune cose che è meglio lasciare invariate (per non dover essere costretti a cambiare l’interfaccia delle chiamate). È il caso dei nomi e dei codici dei campi di database, cambiando i quali si potrebbe causare la modifica dei tag di riferimento nello schema delle API. Il risultato potrebbe essere quello di ricevere un errore nella chiamata.
Aggirare questo è semplice, ed è una norma che io seguo da tempo con successo in tantissimi progetti Instant Developer (sia Foundation che Cloud): dopo essere andati in produzione non cambiare mai il codice delle tabelle e dei campi di database.
Semplice, ma efficacissimo.
