Guida al Linguaggio PHP. Lezione 19. L’Architettura REST API

Ci occupiamo adesso dei Web Services. In primis che cosa sono e le loro differenze. Diciamo che sono dei servizi in grado di fare comunicare fra di loro strutture hardware e software differenti. Per esempio un ‘applicazione scritta in JAVA su Sistema Operativo Linux sarà in grado di comunicare con un’applicazione PHP su SO PHP.

Artchitettutura REST

E’ l’acronimo di REpresentational State Transfer e fu introdotto da Roy Fielding nel 2000 come tesi di dottorato. Con questo termine si intente ogni interfaccia che trasmetta dati attraverso protocollo HTTP senza livelli opzionali ( come nel SOAP) o cookie, ma con dei vincoli che vi andiamo ad elencare

Il sistema deve interagire su una piattaforma client server. Ossia dove il client comunichi su una setta piattaforma del server e quindi non abbiano problemi di comunicazione.

Statelessness

La comunicazione client-server è limitata dal fatto che nessun client venga memorizzato sul server tra le richieste. Ogni richiesta da qualsiasi client deve contenere tutte le informazioni necessarie per soddisfare la richiesta e lo stato della sessione viene mantenuto nel client. Lo stato della sessione può essere trasferito dal server a un altro servizio come un database per mantenere uno stato permanente per un periodo e consentire l’autenticazione. Vedi l’architettura API 2.0. Il client inizia a inviare richieste quando è pronto per passare a un nuovo stato. Mentre una o più richieste sono in sospeso, il client è considerato in transizione .

Cacheability

Riprende il concetto già introdotto nel WWW dove i client e altri intermediari possono memorizzare le risposte nella cache. Le risposte del server possono pertanto provenire dalla cache e non impedire ai client di riutilizzare 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.

Stratificazione multi-tiered

Un cliente non può di norma dire se è collegato direttamente al server finale o ad un intermediario . I server intermedi dunque possono migliorare la scalabilità del sistema abilitando il bilanciamento del carico e fornendo cache condivise. Possono anche applicare al fine di instituire politiche di sicurezza..

Accesso uniforme

I sistemi distribuiti devono essere accessibili in maniera uniforme: ossia ogni risorsa deve avere un indirizzo univoco globale e un punto valido di accesso.

Codice a Richiesta. (opzionale)

I server possono temporaneamente estendere le funzionalità del client trasferendo del codice eseguibile. Come Applet Java o linguaggi di scripting client side come JavaScript. “Code on demand” è l’unico vincolo opzionale.

I Web Services comunicano attraverso le API dei servizi Web che aderiscono ai vincoli architetturali REST e per questo sono chiamate API RESTful.  Sono basate su HTTP sono definite con i seguenti  requisiti

URL di base ad esempio http://api.example.com/resources
un tipo di supporto Internet che definisce gli elementi di dati di transizione di stato (ad esempio, Atom, microformati, application / vnd.collection + json, ) La rappresentazione corrente indica al client come comporre le richieste di transizione a tutti i prossimi stati di applicazione disponibili. Questo potrebbe essere semplice come un URL o complesso come un applet Java.
metodi HTTP standard (ad es. OPTIONS, GET, PUT, POST e DELETE)

Le API accedono o interrogano una risorsa. Ora rimane da comprendere che cosa si nasconda dietro il termine di risorsa. Che effettivamente è abbastanza astratto. Intanto la definizione precisa è Web Resources proprio ad indicare che alla stessa si accede attraverso il web.

Diciamo che una Web Resource è una qualsiasi servizo messo a disposizione del server tramite il quale interagire tramite le API. Gli utenti tramite le API interrogano la risorsa al fine di ricevere un servizio.

Ma quali sono i modi con cui le risorse vengono interrogati?

Sono i metodi che abbiamo già incontrato sopra ossia GET, PUT, POST e DELETE. Vediamo di chiarire con un esempio

Supponiamo di dovere interrogare una determinata risorsa in remoto del tipo

http://api.nome_sito_web.com/risorsa/

In questo caso il metodo

• GET restituisce un elenco di servizi disponibili.
• PUT rimpiazza i servizi con altri
• POST Crea una nuova serie di servizi. Generalmente restituisce il codice 201, viene assegnato una nuova URI della nuova risorsa creata
• DELETE cancella tutto.

E dal modo generico in cui vi ho descritto il tutto si comprende meglio la differenza fra SOAP e REST. Ossia il SOAP è un protocollo e quindi deve obbedire a delle strutture fisse. Il REST è un ‘architetutta e come tale ha un certo grado di libertà nell’essere implementata.