JSON, REST, SOAP, WSDL e SOA: come si collegano tutti insieme

Attualmente sto facendo degli esami e sto lottando attraverso alcuni concetti. Questi sono stati tutti “menzionati” nei miei appunti ma non ho davvero capito come fossero collegati tra loro. Per quanto riguarda la mia comprensione è:

SOA – una soluzione per comunicare i consumatori / fornitori di servizi. (per quanto ne so, questo è il termine generico per tutto il resto)

WSDL: una lingua che descrive il servizio del provider.

SOAP – Un “wrapper” di protocollo XML utilizzato dai servizi per inviare messaggi. Funziona in combinazione con WSDL per fornire i parametri?

REST – Un modello di progettazione simile a SOAP in funzione ma che evita l’XML? (davvero non sono sicuro di questo)

JSON – Un’alternativa all’XML che usa javascript? (non sono sicuro di questo neanche)

Guardandosi intorno in internet non sembra esserci una chiara definizione di cosa siano e di come si collegano.

Immagina di sviluppare un’applicazione web e decidi di disaccoppiare la funzionalità dalla presentazione dell’applicazione, perché offre una maggiore libertà.

Crei un’API e permetti agli altri di implementare anche i loro front-end. Quello che hai appena fatto qui è implementare una metodologia SOA , cioè l’utilizzo di servizi web.

I servizi Web rendono i blocchi funzionali accessibili tramite i protocolli Internet standard, indipendentemente dalle piattaforms e dai linguaggi di programmazione.

Quindi, progettate un meccanismo di interscambio tra il back-end (servizio web) che elabora e genera qualcosa di utile, e il front-end (che consuma i dati), che potrebbe essere qualsiasi cosa. (Un’applicazione Web, mobile o desktop o un altro servizio Web). L’unica limitazione qui è che il front-end e il back-end devono “parlare” nella stessa “lingua”.


È qui che entrano SOAP e REST. Sono i modi standard con cui scegli di comunicare con il servizio web.

SAPONE:

SOAP utilizza internamente XML per inviare dati avanti e indietro. I messaggi SOAP hanno una struttura rigida e l’XML di risposta deve quindi essere analizzato. WSDL è una specifica di quali richieste possono essere fatte, con quali parametri e cosa restituiranno. È una specifica completa della tua API.

RIPOSO:

REST è un concetto di design.

Il World Wide Web rappresenta la più grande implementazione di un sistema conforms allo stile architettonico REST.

Non è rigido come SOAP. I servizi web RESTful utilizzano URI e metodi standard per effettuare chiamate al servizio web . Quando si richiede un URI, viene restituita la rappresentazione di un object, su cui è quindi ansible eseguire operazioni (ad esempio GET, PUT, POST, DELETE). Non sei limitato a scegliere XML per rappresentare i dati, puoi scegliere qualsiasi cosa realmente (incluso JSON)

L’API REST di Flickr va oltre e consente di restituire anche le immagini.


JSON e XML, sono funzionalmente equivalenti e potrebbero essere scelti. L’XML è considerato troppo prolisso e più difficile da analizzare, quindi molte volte i dati vengono rappresentati in modo più adeguato usando JSON. (Es. Serializzazione)

È comunque una scelta.

WSDL : sta per lingua di descrizione del servizio Web

In SOAP (protocollo di accesso agli oggetti semplice), quando si utilizza il servizio Web e si aggiunge un servizio Web al progetto, le applicazioni client non conoscono le funzioni del servizio Web. Oggigiorno è in qualche modo vecchio stile e per ogni tipo di client diverso è necessario implementare diversi file WSDL . Ad esempio non è ansible utilizzare lo stesso file per .Net e il client php . Il file WSDL ha alcune descrizioni sulle funzioni del servizio web. Il tipo di questo file è XML . SOAP è un’alternativa per REST .

REST : Stand per il trasferimento dello stato di rappresentanza

È un altro tipo di servizio API, è davvero facile da usare per i clienti. Non è necessario avere un’estensione di file speciale come i file WSDL . L’operazione CRUD può essere implementata da diversi HTTP Verbs (GET per la lettura, POST per la creazione, PUT o PATCH per l’aggiornamento e DELETE per l’eliminazione del documento desiderato), Si basano sul protocollo HTML e la maggior parte delle volte la risposta è in JSON o XML formato. D’altra parte l’applicazione client deve chiamare esattamente il HTTP Verb correlato tramite nomi e tipi di parametri esatti. A causa della mancanza di file speciali per la definizione, come WSDL , si tratta di un lavoro manuale che utilizza l’endpoint. Ma non è un grosso problema perché ora abbiamo un sacco di plugin per IDE diversi per generare l’implementazione lato client.

SOA : sta per architettura orientata ai servizi

Include tutta la programmazione con i concetti e l’architettura dei servizi web. Immagina di voler implementare un’applicazione su larga scala. Una pratica può avere alcuni servizi diversi, chiamati micro-servizi e l’intero meccanismo di applicazione chiamerebbe il servizio web necessario al momento giusto. Entrambi i servizi web REST e SOAP sono di tipo SOA .

JSON : sta per javascript Object Notation

quando serializzi un object per javascript il tipo di formato object è JSON. immagina di avere la class umana:

 class Human{ string Name; string Family; int Age; } 

e hai alcune istanze di questa class:

 Human h1 = new Human(){ Name='Saman', Family='Gholami', Age=26 } 

quando serializzi l’object h1 su JSON il risultato è:

  [h1:{Name:'saman',Family:'Gholami',Age:'26'}, ...] 

javascript può valutare questo formato con la eval() e creare un array associativo da questa stringa JSON . Questo è un concetto diverso rispetto ad altri concetti che ho descritto precedentemente.