Sei vincoli guida definiscono un sistema RESTful. Questi vincoli limitano i modi in cui il server può elaborare e rispondere alle richieste del client in modo che, operando all’interno di questi vincoli, il sistema ottenga proprietà non funzionali desiderabili, come prestazioni, scalabilità, semplicità, modificabilità, visibilità, portabilità e affidabilità. Se un sistema viola uno qualsiasi dei vincoli richiesti, non può essere considerato RESTful.,

I vincoli REST formali sono i seguenti:

Architettura client–server

Il principio alla base dei vincoli client–server è la separazione delle preoccupazioni. Separare i problemi dell’interfaccia utente dai problemi di archiviazione dei dati migliora la portabilità delle interfacce utente su più piattaforme. Migliora anche la scalabilità semplificando i componenti del server., Forse la cosa più significativa per il Web è che la separazione consente ai componenti di evolversi in modo indipendente, supportando così il requisito su scala Internet di più domini organizzativi.

StatelessnessEdit

In un’interazione client–server, lo stato è costituito da stato intrinseco e stato estrinseco. Lo stato intrinseco, chiamato stato delle risorse, è memorizzato sul server ed è costituito da informazioni indipendenti dal contesto del server, rendendole quindi condivisibili con tutti i client del server., Lo stato estrinseco, chiamato stato dell’applicazione, è memorizzato su ciascun client ed è costituito da informazioni che dipendono dal contesto del server e quindi non possono essere condivise. I client sono responsabili del passaggio dello stato dell’applicazione al server quando ne ha bisogno. Il vincolo di memorizzare lo stato dell’applicazione sul client piuttosto che sul server rende la comunicazione senza stato.

CacheabilityEdit

Come sul World Wide Web, i clienti e gli intermediari possono memorizzare nella cache le risposte., Le risposte devono, implicitamente o esplicitamente, definirsi cacheable o non cacheable per impedire ai clienti di fornire dati obsoleti o inappropriati in risposta a ulteriori richieste. Il caching ben gestito elimina parzialmente o completamente alcune interazioni client-server, migliorando ulteriormente la scalabilità e le prestazioni.

Layered systemEdit

Un client non può normalmente dire se è collegato direttamente al server finale o ad un intermediario lungo la strada., Se un proxy o un bilanciamento del carico viene posizionato tra il client e il server, non influirà sulle loro comunicazioni e non sarà necessario aggiornare il codice client o server. I server intermedi possono migliorare la scalabilità del sistema abilitando il bilanciamento del carico e fornendo cache condivise. Inoltre, la sicurezza può essere aggiunta come livello in cima ai servizi Web, separando la logica di business dalla logica di sicurezza. L’aggiunta di sicurezza come livello separato impone i criteri di sicurezza. Infine, i server intermedi possono chiamare più altri server per generare una risposta al client.,

Codice su richiesta (opzionale)Modifica

I server possono estendere o personalizzare temporaneamente le funzionalità di un client trasferendo codice eseguibile: ad esempio, componenti compilati come applet Java o script lato client come JavaScript.

Uniform interfaceEdit

Il vincolo uniform interface è fondamentale per la progettazione di qualsiasi sistema RESTful. Semplifica e disaccoppia l’architettura, che consente ad ogni parte di evolversi in modo indipendente., I quattro vincoli per questa interfaccia uniforme sono:

Identificazione delle risorse nelle richieste Le singole risorse vengono identificate nelle richieste, ad esempio utilizzando URI nei servizi Web RESTful. Le risorse stesse sono concettualmente separate dalle rappresentazioni che vengono restituite al client. Ad esempio, il server potrebbe inviare dati dal proprio database come HTML, XML o come JSON, nessuno dei quali è la rappresentazione interna del server., Manipolazione delle risorse tramite rappresentazioni Quando un client detiene una rappresentazione di una risorsa, inclusi i metadati allegati, dispone di informazioni sufficienti per modificare o eliminare lo stato della risorsa. Messaggi auto-descrittivi Ogni messaggio include informazioni sufficienti per descrivere come elaborare il messaggio. Ad esempio, quale parser richiamare può essere specificato da un tipo di supporto., Hypermedia come motore dello stato dell’applicazione (HATEOAS) Avendo accesso a un URI iniziale per l’applicazione REST—analogo a un utente Web umano che accede alla home page di un sito Web—un client REST dovrebbe quindi essere in grado di utilizzare dinamicamente i collegamenti forniti dal server per scoprire tutte le risorse disponibili di cui ha bisogno. Man mano che l’accesso procede, il server risponde con testo che include collegamenti ipertestuali ad altre risorse attualmente disponibili. Non è necessario che il client sia codificato con informazioni riguardanti la struttura o la dinamica dell’applicazione.