Sei sulla pagina 1di 5

JSON JavaScript Object Notation

E' un formato leggero di scambio dati tra web application, "indipendente dal linguaggio" che lo
usa che pu essere qualunque, auto descrittivo e facile da capire, alternativo a XML.
Utilizza la sintassi degli oggetti js:
var automonile = {marchio:"Fiat", modello:"500", colore:"bianco"};
A differenza di un oggetto js richiede le virgolette anche per i nomi:
{"marchio":"Fiat","modello":"500", "colore":"bianco"};

SINTASSI
Un dato una coppia --> nome:valore , i dati sono separati da virgole, le parentesi graffe
racchiudono oggetti, le parentesi quadre racchiudono array(anche di oggetti).
Oggetto json:
{"nome":"Mario","cognome":"Rossi"}
Array di oggetti:
"IMPIEGATI":[
{"nome":"Mario","cognome":"Rossi"},
{"nome":"Anna","cognome":"Verdi"},
{"nome":"Giovanni","cognome":"Bianchi"}
]

USO DI JSON
Tipico uso di json e quello di esporre dati in un web server , i dati json vengono letti dal web server
e convertiti in oggetti jscript, gli oggetti js possono essere visualizzati in una pagina web.
Per fare questo jscript puo' utilizzare la seguente istruzione:
var oggetto = JSON.parse(Testo);
dove Testo contiene una stringa json come dalla diapositiva precedente posso poi nel jscript
accedere ai vari campi ad es. Oggetto.impiegati[0].cognome
oppure in php:
$maps_array=json_decode($maps_json,true);
Dove $maps_json conterr una stringa json come esempio 2 della diapositva n.16 posso quindi
accedere nel php ai vari campi esempio $lat=$maps_array['results'][0]['geometry']['location']['lat'];

EQUIVALENTE XML
<impiegati>
<impiegato>
<nome>Mario</nome> <congome>Rossi</cognome>
</impiegato>
<impiegato>
<nome>Anna</nome> <cognome>Verdi</cognome>
</impiegato>
<impiegato>
<nome>Giovanni</nome> <cognome>Bianchi</cognome>
</impiegato>
</impiegati>

SOMIGLIANZE JSON - XML


Entrambi sono auto descrittivi (leggibili dalluomo)
Entrambi sono gerarchici (valori dentro valori)
Entrambi possono essere usati da molti linguaggi di programmazione
Entrambi possono essere caricati con una xmlhttprequest
DIFFERENZE JSON - XML
Json non usa i tag
Json e piu breve
Json e piu veloce da leggere e scrivere
Json puo usare gli array
Caricare con json e piu rapido basta eseguire in un file js
JSON.parse();

REST API
API --> Application Programming Interface
ReST--> RePRESENTATION STATE TRANSFER
Es. Facebook Graph API, Googleapis
Come posso usare le api?
Creare pagine di Mashup
Usare loutput di una API come input di ricerca in unaltra

REST Web Services


Web Service --> servizio esposto su Internet per essere utilizzato da un'applicazione
On Line API --> Remote Application Programming Interface
API Locali --> tutto viene eseguito all'interno di uno stesso ambiente
API Remote -->Alcune funzionalit sono eseguite in ambienti remoti ( es. Apps che usano sevizi
Facebook o Twitter) Le applicazioni come Facebook e Twitter pubblicano i loro servizi permettendo
ai programmatori di usare le loro funzionalit.
Confronto con un sito web:
Applicazione web ad uso e consumo dell'utente finale( formato HTML(+css +js)=dati+UI)
Web API ad uso e consumo di un'applicazione( formato XML/JSON=dati) Differenti URL per le
differenti aperazioni.
TIPI DI WEB SERVICE:
SOAP web service
Classico
Standardizzato W3C
Meno leggero
REST web service
Moderno
Leggero
Sfrutta completamente i messaggi HTTP e gli URL
Non standard
COME FUNAZIONA HTTP:
-La risposta contiene solo dati
-Il client pu contenere la logica di presentazione( per l'utente)

PROTOCOLLI: come formalizzare le richieste, le risposte e il formato di dati?


Nel caso di soap: il formato dei messaggi e dei dati standardizzato:
SOAP request, SOAP response
WSDL (service description)
XML (data rapresentation)
Nel caso dei Rest web service: Non c' standard, non ci sono regole.

METODI HTTP: il protocollo HTTP ha diversi metodi per effettuare la richiesta: GET, POST,
HEAD, PUT, DELETE,TRACE....
Definizione del servizio:
Descrzione del servizio--> metodi e parametri (interfaccia)
SOAP web service: WSDL(Web Service Definition Language--> documento che definisce i
dettagli del servizio) + Standard
Riassumendo, REST Web Service:
Non ci sono regole per il funzionamento
Non ci sono protocolli standard
Non ci sono canali di comunicazione standard
Non ci sono definizioni del servizio standard
Non ci sono formati di rappresentazione dati standard
REST vs SOAP
SOAP definisce e standardizza ogni cosa
Per questo rigoroso ma pesante
Se non si eseguono le regole non funziona nulla
REST lascia complet libert
Quindi pi flessibile e leggero
E' un concetto, una filosofia
Non ci sono specifiche
RESTful Web Srvice: si basa sui metodi HTTP e su URL, inventato da Ror Fielding (lo stesso che
ha scritto il protocollo HTTP.
REST-->REoresentational State Transfer, uno stile di realizzazione di Web Service ma occore
prendere delle decisioni. REST una guida come pu essere un'architettura di remote API, se
applichiamo i concetti di REST ai web service e adottiamo le scelte di Roy Fielding otteniamo il
RESTful Web Service il cui scopo ottenere Web Service molto "pratici" senza "troppe" regole ed
facile da usare(remote API facili da invocare da parte delle applicazioni consumer) e ha solo regole
essenziali( servizi semplici da mantenere).

REST e HTTP--> il concetto di REST intimamente legato al funzionamento di HTTP quest'ultimo


la base del web, formalizzato da specifiche e da regole, su questo appoggia REST che non ha
regole. HTTP = Hyper Text Transfer Protocol, i contenuti che si scambiano con HTTP sono
ipertesti. Un ipertesto un testo che contiene "collegamenti" ad altro testo. HTML = Hyper Text
Markup Language, linguaggio per scrivere ipertesti. Ipertesto, collegamenti e HTML sono elementi
delle pagine web. Ma cosa unisce HTTP ai servizi REST? Innanzitutto il concetto di Resource
Location. Cos come le pagine web, i REST web service utilizzano gli URL questo li rende a prima
vista simili a pagine web ma con un'importante differenza: aquesti URL(web API) non
corrispondono risposte leggibili per l'uomo(come le pagine HTML) ma solo dati.
Web API = indirizzi : sono sostanzialmente "indirizzi", ma lo sviluppatore deve sapere esattamente
come deve essere definito e cosa esso rappresenti. Il principio sul basa sul fatto che essi
rappresentino RISORSE.
Indirizzi: un indirizzi che rappresenta la pagina " meteo della citt di cui dato il cap" potrebbe
essere: weather.com/lookup?zipcode=12345 questo non un indirizzo che identifica una risorsa (
pi un'azione con parametro)
URI Uniform Resource Identifier: idicano univocamente una risorsa ( e sono indipendenti
dall'implementazione), ad esempio l'indirizzo che rappresenta la risorsa "meteo della citt con un
dato cap" potrebbe essere: weather.com/zipcode/12345 questo non indica un'azione ma come se
prendessimo qualcosa che esiste gi altro es. weather.com/countries/italy. N.B. Dietro ad ogni
richiesta il server compie del lavoro, ma sembra che facciamo semplicemente il lookup di qualcosa
gi esistente.
Metodi HTTP--> una volta stabilito come l'indirizzo, con quale metodo inviamo la richiesta?
GET(richiede informazioni al server), POST(invia informazioni al server), PUT(invia informazioni
al server), DELETE(elimina informazioni dal server). Un buon RESTful Web Service fa uso
corretto di tutti i metodi HTTP. Ogni metodo fa qualcosa di specifico: GET richiede una risorsa,
POST crea una risorsa, PUT modifica una risorsa, DELETE rimuove una risorsa, il metodo da usare
per ogni API dipende dall'azione che tale API deve svolgere.
METADATI: una volta stabilito URI e metodo quale risposta ottengo dal server? HTTP definisce
degli STATUS CODE: 200 OK, 404 NOT FOUND, 500 SERVER ERROR. Fanno parte del
messaggio HTTP di risposta(che conterr anche i dati richiesti al servizio). Perch usare gli status
code? Se si accede ad un sito web e qualcosa va storto il browser mostra una pagina o un messaggio
all'utente. Il destinatario di un RESTful web srvice un'applicazione e quindi il codice di stato
rappresenta correttamente l'esito della richiesta.
FORMATO DEI MESSAGGI: quale formato utilizzare per rappresentare i dati da inviare al server
o ricevuti dal server? Non ci sono specifiche a riguardo ma spesso si usano: XML, JSON, TEXT.
Come dire al server quale formato usare? Si usa il valore Content-Type presente nell'headr del
messagio HTTP: text/xml, application/json. Una stessa API potrebbe ritornare dati in formati
diversi, il formato viene applicato in base alla richiesta del client--> content negotiation.
URI: ogni URI di unREST WS deve riferirsi ad una risorsa, se pensiamo all'URL di una pagina Web
che mostra un messaggio /getMessages.do?Id=10 non necessario memorizzare questi URL perch
di solito sono link che l'utente pu selezionare. Se pensiamo ad una REST WebAPI il
programmatore deve conoscere l'URI, per facilitarne l'individuazione serve una convenzione pratica
e chiara-->best practice.
IL WEB ALLE ORIGINI: In origine le pagine web erano statiche(gi esistenti), ogni pagina ha un
suo indirizzo URL, pertanto ogni URL si rifesci ad una specifica risorsa(unica e statica) e quanto si
progetta un WS REST l'idea quella di pensare ad un sito statico. Resorce based URI-->contengono
sostantivi(non verbi), si usa il plurale(messages, profiles...), questa la base per progettare WebAPI
o RESTful WS-->identificare le risorse. Le URI non dipendono dalla tecnologia software utilizzata,
e sono resistenti ai cambiamenti.
TIPI DI URI RESTFUL: gli URI possono riferirsi a: Istanze(una singola risorsa /messages/
{messageId}), Collezioni(un insieme di risorse /messages).
FILTRAGGIO DEI DATI: l'applicazione client potrebbe paginare i risultati ma...si possono usare le
query parametriche: /message?offset=30&limit=10.

METODI E URI
Il singolo URI identifica la risorsa /massage/10 ma non l'azione che si vuole compiere sulla risorsa.
Nel caso di applicazioni web potremmo avere URL che specifica azioni /getMessage.jsp?Id=10
/updateMessage.php?Id=10 /deleteMessage.asp?Id=10, nel caso di SOAP potremmo avere metodi
invocati nel messaggio
POST /globalweather.asmx HTTP/1.1
Host:www.webservicex.net
Content-Type: text/xml;
SOAPAction: "http://www.webserviceX.NET/GetWeather
Come si fa con un unico URI a specificare diverse azioni? Usando i diversi metodi HTTP
PROPRIETA' DEI METODI HTTP
PUT vs POST--> PUT per aggoirnare una risorsa esistente, POST per aggiungere una nuova risorsa.
GET-->read-only methond metodo di sola lettura ,nulla cambia sulla risorsa del server se viene
invoxato pi volte , un metodo "safe", POST,PUT,DELETE-->write methods, metodi di scrittura
modificano lo stato della risorsa.
RIPETIBILITA'--> importante propriet di un metodo: operazione ripetibile oppure operazione non
ripetibile. GET PUT e DELETE sono "safely repeatable", POST cannot be repeated safely. Quindi
si dice che i primi 3 sono idempotenti cio possono essre invocati ripetutamente senza problemi
mentre POST un metodo non idempotente non pu essere invocato ripetutamente.
In informatica, matematica e in particolare algebra, l'idempotenza una propriet delle funzioni per
laquale applicando molteplici volte una data funzione, il risultato ottenuto uguale a quelli
derivante dall'applicazione della funzione un'unica volta.
RESTful web service-->la scelta dei metodi PUT e POST con questa implementazione
obbligatoria, se non si segue la regole le nostre WebAPI potrebbero confondere il client.
CACHING DEI DATI(GET response)-> il server crea una copia cache di dati cos che una
successiva richiesta non carichi di lavoro il server.
BROWSER: Refresh di un metodo GET--> il browser invia nuovamente la richiesta nessun
problema, Refresh di un metodo POST(riinvio di dati di una form) il browser allerta l'utente del
fatto che i dati vengono riinviati -->possibili problemi(se sono i dati di un ordine o di un
pagamento?)

JSON sta diventando molto popolare pi compatto rispetto a XML, pi adatta a client browser che
usano Javascript.
REST Representational State Transfer un modo per trasferire la rappresentazione di una risorsa, la
rappresentazione pu avere diversi formati: JSON XML. Il client pu chiedere un particolare
formato sia supportato dal server. Nella header del messaggio si hanno i campi: Message Length,
Date, Content Type quest'ultimo usato per indicare il formato dei dati contenuti nel masseggio. Lo
STATUS CODE(200,404,500) la prima riga del messaggio HTTP di risposta, al programma
interessa il codice numerico (il testo un promemoria per il programmatore).
Classe di status code: 1XX INFORMATIONAL, 2XX SUCCES, 3XX REDIRECTION, 4XX
CLIENT ERROR, 5XX SERVER ERROR.

HATEOAS Hypermedia As The Engine Of Application State --> i REST WS si basano su HTTP il
quale un protocollo di trasferimento di ipertesti cio di link quindi inseriamo nelle risposte del
server link ad altre risorse correlate. Il client pu sapere quali risorse sono collegate alla risorsa
ottenuta e pu fare ulteriori richieste utilizzando gli URI contenuti nella risposta. Poich il client
sfruttando questi link in grado di usare il servizio si dice che i link sono la guida (o il motore) del
servizio da qui il nome Hypermedia As The Engine Of Application State.

Lo scopo di REST creare WebAPI facili da usare, da capire, da mantenere.