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.