Java REST e RESTful: fondamenti e filosofia

Nelle prossime righe verranno illustrati un insieme di principi di progettazione che dovrebbero essere rispettati quando si crea una web service RESTful.

java REST AND RESTFUL mobile app Italia 2014
java REST AND RESTFUL

REST è una Representational State Transfer.
REST è lo stile architettonico del web stesso.

REST è uno stile architecturale.

REST si riferisce ad un insieme di principi di architetture di rete, i quali specificanola forma come le risorse sono definite e indirizzate.

Esso si basa su rapporti client-server, utilizzando un protocollo di comunicazione cacheable (in memoria), stateless (comunicazione senza stato) e a livelli.
REST è indipendente dal protocollo. Non è accoppiato ad HTTP. Al giorno d’oggi, molte applicazioni REST
sono costruite utilizzando il protocollo HTTP, tuttavia REST non è legato ad questo specifico protocollo.
Un’applicazione REST può utilizzare qualsiasi protocollo per i quali esista uno schema URI standardizzato.

HTTP e REST Insieme contribuiscono a creare una struttura semplice e leggera, con cui si possono costruire applicazioni web complesse.
Al centro di REST con HTTP, sono i metodi HTTP.

Essi possono essere liberamente pensati come operazioni CRUD,
-creare(Create) leggere(Read) aggiornare(Upload) e cancellare(Delete) dei dati o delle risorse-
Sfruttando i metodi HTTP, un’applicazione REST offre spesso rappresentazioni POST, GET, PUT e DELETE per le operazioni CRUD.

FONDAMENTI DI REST
Identificazione delle risorse
Utilizzo esplicito dei metodi HTTP
Risorse autodescrittive
Collegamenti tra risorse
Comunicazione senza stato

REST NON è:
REST non è la mappatura o rappresentazione CRUD dei metodi HTTP.  REST non è REST senza HATEOAS. REST non è uno stile architetturale solo web/mobile application. ma ha un utilizzo più generale.

CARATTERISTICHE NECESSARIE PER DIVENTARE RESTFUL

Lo stile architetturale REST descrive sei regole caratteristiche per diventare Restfull.

  • Client/Server – Un insieme di interfacce uniformi separa i client dai server. Questa separazione di ruoli e attività significa che, per esempio, il client non si deve preoccupare del salvataggio delle informazioni, che rimangono all’interno di ogni singolo server, in questo modo la portabilità del codice del client ne trae vantaggio. I server non si devono preoccupare dell’interfaccia grafica o dello stato dell’utente, in questo modo i server sono più semplici e maggiormente scalabili. Server e client possono essere sostituiti e sviluppati indipendentemente fintanto che l’interfaccia non viene modificata.
  • Comunicazione libera di stato (senza stato) -La comunicazione client–server è ulteriormente vincolata in modo che in nessun contesto il client venga memorizzato (comunicato)  sul server tra le richieste. Ogni richiesta da ogni client contiene tutte le informazioni necessarie per richiedere il servizio, e lo stato della sessione è contenuto sul lato client. Lo stato della sessione può essere trasferito al server attraverso un altro servizio che controlla la persistenza (stato dei dati di un database).
  • Cacheable (utilizzabile in memoria temporanea) – Come nel World Wide Web, i client possono fare caching delle risposte. Le risposte devono in ogni modo definirsi implicitamente o esplicitamente cacheable o no, in modo da prevenire che i client possano riusare stati vecchi o dati errati. Una gestione ben fatta della cache può ridurre o parzialmente eliminare le comunicazioni client server, migliorando scalabilità e performance.
  • Organizzato a livelli – Un client non può dire se è connesso direttamente ad un server di livello più basso od intermedio, i server intermedi possono migliorare la scalabilità del sistema con load-balancing o con cache distribuite. livelli  intermedi possono offrire inoltre delle politiche di sicurezza.
  • Codice a Richiesta (non obbligatorio) – I server possono temporaneamente estendere o personalizzare le funzionalità del client trasferendo del codice eseguibile. Ad esempio questo può includere componenti compilati come Applet Java o linguaggi di scripting client side come JavaScript.
  • Interfaccia uniforme – Un’interfaccia di comunicazione omogenea tra client e server permette di semplificare e disaccoppiare l’architettura, la quale si può evolvere separatamente.

FILOSOFIA  REST

  • Tutto è una risorsa
  • Ogni risorsa ha un ID.
    L’ID è un URI.
    Un URI può identificare oggetti.
  • Tutte le risorse espongono un’interfaccia standard
  • Tutte le operazioni REST devono essere sicure ( l’operazione non deve avere effetti collaterali ); cacheable ( il risultato può essere memorizzato nella cache, ad esempio da un server proxy); concrete e integre ( L’operazione deve sempre restituire lo stesso – unico risultato).
  • ogni risorse può contenere collegamenti ad altre risorse.comunicazione senza stato Ogni cosa che necessita processare una richiesta deve essere contenuto nella richiesta estesa (conformazione). Non esistono sessioni dei client nel Server.

REST E Risorse: Le risorse sono sostantivi (oggetti – cose – nomi) . Le risorse sono identificate da URI.

      http:/myApp/medici/8456201
      http:/myApp/medici/usl/5

REST E Metodi: I metodi sono verbi (azioni, attività da fare sulle risorse) . Essi svolgono operazioni CRUD.
   metodi sono: POST, GET, PUT, DELETE

REST E Rappresentazione delle risposte/soluzioni:
Il formato per rappresentare le  risorse spesso è XML o JSON, (utilizzabile anche PDF / text / word).

per saperne di più … altre fonti

 

 

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

w

Connessione a %s...