REST sta per Representational State Transfer, un termine coniato da Roy Fielding nel 2000. È uno stile di architettura per la progettazione di applicazioni liberamente accoppiate su HTTP, che viene spesso utilizzato nello sviluppo di servizi web. REST non applica alcuna regola su come dovrebbe essere implementato a un livello inferiore, ma mette solo linee guida di progettazione di alto livello e ti lascia pensare alla tua implementazione.
Nel mio ultimo impiego, ho progettato API RESTful per una grande azienda di telecomunicazioni per due buoni anni. In questo post, condividerò i miei pensieri a parte le pratiche di progettazione standard. Potresti non essere d’accordo con me su alcuni punti, e questo è perfettamente OK. Sarò felice di discutere qualsiasi cosa da voi con una mente aperta.
Iniziamo con cose specifiche di progettazione standard per chiarire ciò che ‘Roy Fielding’ vuole che costruiamo. Poi discuteremo i miei pensieri, che saranno più verso punti più fini mentre si progettano le API RESTful.
Vincoli architettonici
REST definisce 6 vincoli architettonici che rendono qualsiasi servizio web una vera API RESTful.
- interfaccia Uniforme
- Client–server
- Stateless
- Cacheable
- sistema a Strati
- Codice a richiesta (optional)
interfaccia Uniforme
Come il nome del vincolo stesso vale, è NECESSARIO decidere le Api di interfaccia per le risorse all’interno del sistema che sono esposti alle API consumatori e seguire religiosamente. Una risorsa nel sistema dovrebbe avere un solo URI logico e questo dovrebbe fornire un modo per recuperare dati correlati o aggiuntivi. È sempre meglio sinonimizzare una risorsa con una pagina web.
Ogni singola risorsa non dovrebbe essere troppo grande e contenere ogni cosa nella sua rappresentazione. Ogni volta che è rilevante, una risorsa dovrebbe contenere collegamenti (HATEOAS) che puntano a URI relativi per recuperare informazioni correlate.
Inoltre, le rappresentazioni delle risorse nel sistema dovrebbero seguire linee guida specifiche come convenzioni di denominazione, formati di collegamento o formato dati (XML o/e JSON).
Tutte le risorse dovrebbero essere accessibili attraverso un approccio comune come HTTP GET e modificate in modo simile utilizzando un approccio coerente.
Client–server
Questo vincolo significa essenzialmente che l’applicazione client e l’applicazione server DEVONO essere in grado di evolversi separatamente senza alcuna dipendenza l’una dall’altra. Un client dovrebbe conoscere solo URI di risorse, e questo è tutto. Oggi, questa è la pratica standard nello sviluppo web, quindi non è richiesto nulla di speciale dalla tua parte. Sii semplice.
Stateless
Roy fielding ha preso ispirazione da HTTP, quindi si riflette in questo vincolo. Rendi tutte le interazioni client-server senza stato. Il server non memorizzerà nulla sull’ultima richiesta HTTP effettuata dal client. Tratterà ogni richiesta come nuova. Nessuna sessione, nessuna storia.
Se l’applicazione client deve essere un’applicazione stateful per l’utente finale, in cui l’utente accede una volta e successivamente esegue altre operazioni autorizzate, ogni richiesta del client deve contenere tutte le informazioni necessarie per soddisfare la richiesta, inclusi i dettagli di autenticazione e autorizzazione.
Cacheable
Nel mondo di oggi, la memorizzazione nella cache di dati e risposte è della massima importanza ovunque siano applicabili/possibili. La pagina web che stai leggendo qui è anche una versione memorizzata nella cache della pagina HTML. Il caching migliora le prestazioni per il lato client e migliora l’ambito di scalabilità per un server perché il carico è ridotto.
In REST, il caching deve essere applicato alle risorse quando applicabile e quindi queste risorse DEVONO dichiararsi memorizzabili nella cache. Il caching può essere implementato sul server o sul lato client.
Sistema a livelli
REST consente di utilizzare un’architettura di sistema a livelli in cui distribuire le API sul server A, archiviare i dati sul server B e autenticare le richieste nel server C, ad esempio. Un client non può normalmente dire se è collegato direttamente al server finale o un intermediario lungo la strada.
Codice su richiesta (opzionale)
Bene, questo vincolo è facoltativo. La maggior parte delle volte, invierai le rappresentazioni statiche delle risorse sotto forma di XML o JSON. Ma quando è necessario, sei libero di return executable code per supportare una parte della tua applicazione, ad esempio, i client possono chiamare la tua API per ottenere un codice di rendering del widget dell’interfaccia utente. È permesso.
Si noti che tutti i vincoli di cui sopra sono più strettamente correlati a WWW (il web). Utilizzando le API RESTful, puoi fare la stessa cosa con i tuoi servizi Web che cosa fai alle pagine Web.