REST sta per REpresentational State Transfer.
REST è un'architettura basata su standard web e utilizza il protocollo HTTP per la comunicazione dei dati. Ruota attorno a una risorsa in cui ogni componente è una risorsa e si accede a una risorsa tramite un'interfaccia comune utilizzando metodi standard HTTP. REST è stato introdotto per la prima volta da Roy Fielding nel 2000.
Nell'architettura REST, un server REST fornisce semplicemente l'accesso alle risorse e il client REST accede e presenta le risorse. Qui ogni risorsa è identificata da URI / ID globali. REST utilizza varie rappresentazioni per rappresentare una risorsa come testo, JSON e XML. Al giorno d'oggi JSON è il formato più popolare utilizzato nei servizi web.
I seguenti metodi HTTP ben noti sono comunemente usati nell'architettura basata su REST:
GET - Fornisce accesso in sola lettura a una risorsa.
PUT - Utilizzato per aggiornare una risorsa esistente o creare una nuova risorsa.
DELETE - Usato per rimuovere una risorsa.
POST - Usato per creare una nuova risorsa.
OPTIONS - Utilizzato per ottenere le operazioni supportate su una risorsa.
Un servizio Web è una raccolta di protocolli aperti e standard utilizzati per lo scambio di dati tra applicazioni o sistemi. Le applicazioni software scritte in vari linguaggi di programmazione e in esecuzione su varie piattaforme possono utilizzare i servizi web per scambiare dati su reti di computer come Internet in un modo simile alla comunicazione tra processi su un singolo computer.
I servizi Web basati sull'architettura REST sono noti come servizi Web RESTful. Questi servizi Web utilizzano metodi HTTP per implementare il concetto di architettura REST. Un servizio Web RESTful di solito definisce un URI, Uniform Resource Identifier un servizio, fornisce una rappresentazione delle risorse come JSON e un insieme di metodi HTTP.
L'architettura REST tratta ogni contenuto come una risorsa. Queste risorse possono essere file di testo, pagine html, immagini, video o dati aziendali dinamici. Il server REST fornisce semplicemente l'accesso alle risorse e il client REST accede e modifica le risorse. Qui ogni risorsa è identificata da URI / ID globali.
REST utilizza varie rappresentazioni per rappresentare una risorsa in cui testo, JSON, XML. XML e JSON sono le rappresentazioni più popolari delle risorse.
Di seguito sono riportati punti importanti da considerare durante la progettazione di un formato di rappresentazione di una risorsa in un servizio Web RESTful:
Understandability - Sia il server che il client dovrebbero essere in grado di comprendere e utilizzare il formato di rappresentazione della risorsa.
Completeness- Il formato dovrebbe essere in grado di rappresentare completamente una risorsa. Ad esempio, una risorsa può contenere un'altra risorsa. Il formato dovrebbe essere in grado di rappresentare strutture di risorse semplici e complesse.
Linkablity - Una risorsa può avere un collegamento a un'altra risorsa, un formato dovrebbe essere in grado di gestire tali situazioni.
I servizi Web RESTful utilizzano il protocollo HTTP come mezzo di comunicazione tra client e server.
Un client invia un messaggio sotto forma di una richiesta HTTP e il server risponde sotto forma di una risposta HTTP. Questa tecnica viene definita messaggistica. Questi messaggi contengono dati e metadati del messaggio, ovvero informazioni sul messaggio stesso.
Una richiesta HTTP ha cinque parti principali:
Verb - Indica metodi HTTP come GET, POST, DELETE, PUT ecc.
URI - Uniform Resource Identifier (URI) per identificare la risorsa sul server.
HTTP Version - Indicare la versione HTTP, ad esempio HTTP v1.1.
Request Header- Contiene i metadati per il messaggio di richiesta HTTP come coppie chiave-valore. Ad esempio, tipo di client (o browser), formato supportato dal client, formato del corpo del messaggio, impostazioni della cache ecc.
Request Body - Contenuto del messaggio o rappresentazione delle risorse.
Una risposta HTTP ha quattro parti principali:
Status/Response Code- Indicare lo stato del server per la risorsa richiesta. Ad esempio 404 significa che la risorsa non è stata trovata e 200 significa che la risposta è ok.
HTTP Version - Indicare la versione HTTP, ad esempio HTTP v1.1.
Response Header- Contiene i metadati per il messaggio di risposta HTTP come coppie chiave-valore. Ad esempio, lunghezza del contenuto, tipo di contenuto, data di risposta, tipo di server ecc.
Response Body - Contenuto del messaggio di risposta o rappresentazione delle risorse.
L'indirizzamento si riferisce all'individuazione di una o più risorse che si trovano sul server. È analogo individuare un indirizzo postale di una persona.
URI sta per Uniform Resource Identifier. Ogni risorsa nell'architettura REST è identificata dal relativo URI.
Lo scopo di un URI è individuare una o più risorse sul server che ospita il servizio web.
Un URI ha il seguente formato:
<protocol>://<service-name>/<ResourceType>/<ResourceID>VERB identifica l'operazione da eseguire sulla risorsa.
Di seguito sono riportati punti importanti da considerare durante la progettazione di un URI:
Use Plural Noun- Usa un nome plurale per definire le risorse. Ad esempio, abbiamo utilizzato gli utenti per identificare gli utenti come una risorsa.
Avoid using spaces - Usa il carattere di sottolineatura (_) o il trattino (-) quando usi un nome di risorsa lungo, ad esempio, usa authorized_users invece di% 20users autorizzati.
Use lowercase letters - Sebbene l'URI non faccia distinzione tra maiuscole e minuscole, è buona norma mantenere l'URL solo in lettere minuscole.
Maintain Backward Compatibility- Poiché il servizio Web è un servizio pubblico, una volta reso pubblico dovrebbe essere sempre disponibile un URI. Nel caso in cui l'URI venga aggiornato, reindirizza l'URI precedente al nuovo URI utilizzando il codice di stato HTTP, 300.
Use HTTP Verb- Usa sempre verbo HTTP come GET, PUT e DELETE per eseguire le operazioni sulla risorsa. Non è consigliabile utilizzare i nomi delle operazioni nell'URI.
Secondo l'architettura REST, un servizio web RESTful non dovrebbe mantenere uno stato client sul server. Questa restrizione è chiamata apolidia. È responsabilità del client passare il proprio contesto al server e quindi il server può memorizzare questo contesto per elaborare l'ulteriore richiesta del client. Ad esempio, la sessione gestita dal server viene identificata dall'identificatore di sessione passato dal client.
Di seguito sono riportati i vantaggi dell'apolidia nei servizi Web RESTful:
I servizi Web possono trattare ogni richiesta di metodo in modo indipendente.
I servizi Web non devono mantenere le interazioni precedenti del cliente. Semplifica la progettazione dell'applicazione.
Poiché HTTP è esso stesso un protocollo di apolidia, i servizi Web RESTful funzionano perfettamente con il protocollo HTTP.
Di seguito è riportato lo svantaggio dell'apolidia nei servizi Web RESTful:
I servizi Web devono ottenere informazioni aggiuntive in ogni richiesta e quindi interpretarle per ottenere lo stato del client nel caso in cui sia necessario occuparsi delle interazioni con il cliente.
Operazioni idempotenti significa che il loro risultato sarà sempre lo stesso indipendentemente da quante volte queste operazioni vengono invocate.
Le operazioni PUT e DELETE sono idempotenti.
Le operazioni GET sono di sola lettura e sono sicure.
Le operazioni PUT e POST sono quasi le stesse con la differenza che risiede solo nel risultato in cui l'operazione PUT è idempotente e l'operazione POST può causare risultati diversi.
Dovrebbe elencare le operazioni supportate in un servizio Web e dovrebbe essere di sola lettura.
Dovrebbe restituire solo intestazione HTTP, nessun corpo e dovrebbe essere di sola lettura.
La memorizzazione nella cache si riferisce alla memorizzazione della risposta del server nel client stesso in modo che un client non abbia bisogno di fare ripetute richieste al server per la stessa risorsa. Una risposta del server dovrebbe contenere informazioni su come eseguire una memorizzazione nella cache in modo che un client memorizzi nella cache la risposta per un periodo di tempo o non memorizzi mai nella cache la risposta del server.
L'intestazione della data fornisce la data e l'ora della risorsa quando è stata creata.
L'intestazione Ultima modifica fornisce la data e l'ora della risorsa in cui è stata modificata l'ultima volta.
Cache-Control è l'intestazione principale per controllare la memorizzazione nella cache.
L'intestazione Expires imposta la data di scadenza e l'ora della memorizzazione nella cache.
La direttiva pubblica indica che la risorsa può essere rimossa da qualsiasi componente.
La direttiva privata indica che la risorsa può essere memorizzata solo da client e server, nessun intermediario può memorizzare la risorsa nella cache.
La direttiva no-cache / no-store indica che la risorsa non è rimovibile.
La direttiva max-age indica che la memorizzazione nella cache è valida fino a max-age in secondi. Successivamente, il cliente deve fare un'altra richiesta.
La direttiva must-revalidate fornisce l'indicazione al server di riconvalidare la risorsa se max-age è passato.
Mantieni sempre contenuti statici come immagini, CSS, JavaScript memorizzabile nella cache, con data di scadenza da 2 a 3 giorni. Non mantenere mai la data di scadenza troppo alta.
I contenuti dinamici dovrebbero essere memorizzati nella cache solo per poche ore.Poiché i servizi Web RESTful funzionano con i percorsi degli URL HTTP, è molto importante salvaguardare un servizio Web RESTful nello stesso modo in cui viene protetto un sito Web. Di seguito sono riportate le migliori pratiche da seguire durante la progettazione di un servizio web RESTful:
Validation- Convalida tutti gli input sul server. Proteggi il tuo server dagli attacchi di iniezione SQL o NoSQL.
Session based authentication - Utilizzare l'autenticazione basata sulla sessione per autenticare un utente ogni volta che viene effettuata una richiesta a un metodo del servizio Web.
No sensitive data in URL - Non utilizzare mai nome utente, password o token di sessione nell'URL, questi valori devono essere passati al servizio Web tramite il metodo POST.
Restriction on Method execution- Consenti l'uso limitato di metodi come GET, POST, DELETE. Il metodo GET non dovrebbe essere in grado di eliminare i dati.
Validate Malformed XML/JSON - Verificare la presenza di un input ben formato passato a un metodo di servizio Web.
Throw generic Error Messages - Un metodo di servizio Web dovrebbe utilizzare messaggi di errore HTTP come 403 per mostrare l'accesso vietato ecc.
I codici di stato HTTP sono codici standard e si riferiscono allo stato predefinito dell'attività eseguita sul server. Ad esempio, lo stato HTTP 404 indica che la risorsa richiesta non è presente sul server.
Significa, OK, mostra successo.
Significa, CREATO, quando una risorsa viene creata con successo utilizzando la richiesta POST o PUT. Restituire il collegamento alla risorsa appena creata utilizzando l'intestazione della posizione.
Significa, NO CONTENT, quando il corpo della risposta è vuoto, ad esempio, una richiesta DELETE.
Significa, NON MODIFICATO, utilizzato per ridurre l'utilizzo della larghezza di banda della rete in caso di richieste GET condizionali. Il corpo della risposta dovrebbe essere vuoto. Le intestazioni dovrebbero avere data, posizione ecc.
Significa, BAD REQUEST, afferma che viene fornito un input non valido, ad esempio errore di convalida, dati mancanti.
Significa, VIETATO, afferma che l'utente non ha accesso al metodo utilizzato, ad esempio, elimina l'accesso senza diritti di amministratore.
Significa, NON TROVATO, afferma che il metodo non è disponibile.
Significa CONFLITTO, indica una situazione di conflitto durante l'esecuzione del metodo, ad esempio, aggiungendo una voce duplicata.
Significa, ERRORE SERVER INTERNO, afferma che il server ha generato qualche eccezione durante l'esecuzione del metodo.
JAX-RS sta per API JAVA per servizi Web RESTful. JAX-RS è un'API e una specifica del linguaggio di programmazione basato su JAVA per fornire supporto per i servizi Web RESTful creati. La sua versione 2.0 è stata rilasciata il 24 maggio 2013. JAX-RS fa un uso massiccio delle annotazioni disponibili da Java SE 5 per semplificare lo sviluppo della creazione e distribuzione di servizi web basati su JAVA. Fornisce inoltre supporti per la creazione di client per i servizi Web RESTful.