Qualcuno può spiegare cos'è REST e cos'è SOAP in un inglese semplice? E come funzionano i servizi Web?

Spiegazione semplice su SOAP e REST

SOAP - "Simple Object Access Protocol"

SOAP è un metodo per trasferire messaggi o piccole quantità di informazioni su Internet. I messaggi SOAP sono formattati in XML e vengono generalmente inviati tramite HTTP (protocollo di trasferimento ipertestuale).

Riposo: trasferimento dello stato rappresentativo

Il riposo è un modo semplice di inviare e ricevere dati tra client e server e non ha molti standard definiti. È possibile inviare e ricevere dati come JSON, XML o anche testo semplice. È leggero rispetto al sapone.

Entrambi i metodi sono utilizzati da molti dei grandi giocatori. È una questione di preferenza. La mia preferenza è REST perché è più semplice da usare e da capire.

SOAP (Simple Object Access Protocol):

• SOAP crea un protocollo XML su HTTP o talvolta TCP / IP.
• SOAP descrive funzioni e tipi di dati.
• SOAP è un successore di XML-RPC ed è molto simile, ma descrive un modo standard di comunicare.
• Numerosi linguaggi di programmazione hanno il supporto nativo per SOAP, in genere gli si fornisce un URL del servizio Web e si possono chiamare le sue funzioni del servizio Web senza la necessità di un codice specifico.
• I dati binari inviati devono essere prima codificati in un formato come codificato base64.
• Ha diversi protocolli e tecnologie ad esso correlati: WSDL, XSD, SOAP, WS-Addressing

Trasferimento statale rappresentativo (REST):

• Non è necessario che REST sia su HTTP ma la maggior parte dei miei punti di seguito avrà un bias HTTP.
• REST è molto leggero, dice aspetta un minuto, non abbiamo bisogno di tutta questa complessità creata da SOAP.
• In genere utilizza i normali metodi HTTP anziché un grande formato XML che descrive tutto. Ad esempio, per ottenere una risorsa che usi HTTP GET, per mettere una risorsa sul server usi HTTP PUT. Per eliminare una risorsa sul server utilizzare HTTP DELETE.
• REST è molto semplice in quanto utilizza i metodi HTTP GET, POST e PUT per aggiornare le risorse sul server.
• REST è in genere utilizzato al meglio con Resource Oriented Architecture (ROA). In questo modo di pensare, tutto è una risorsa e tu opereresti su queste risorse.
• Finché il tuo linguaggio di programmazione ha una libreria HTTP, e la maggior parte lo fanno, puoi utilizzare un protocollo HTTP REST molto facilmente.
• I dati binari o le risorse binarie possono essere semplicemente consegnati su loro richiesta.

Ci sono dibattiti senza fine su REST vs SOAP su google .

Il mio preferito è questo . Aggiornamento del 27 novembre 2013: il sito di Paul Prescod sembra non essere più in linea e questo articolo non è più disponibile, ma le copie possono essere trovate sulla Wayback Machine o come PDF su CiteSeerX .

RIPOSO

Capisco l'idea principale di REST è estremamente semplice. Usiamo i browser Web da anni e abbiamo visto quanto sono facili, flessibili, performanti, ecc. I siti HTML utilizzano collegamenti ipertestuali e moduli come mezzo principale di interazione dell'utente. Il loro obiettivo principale è quello di consentire a noi clienti di conoscere solo quei collegamenti che possiamo usare nello stato attuale . E REST dice semplicemente "perché non usare gli stessi principi per guidare i computer anziché i client umani attraverso la nostra applicazione?" Combina questo con la potenza dell'infrastruttura WWW e otterrai uno strumento killer per la creazione di grandi applicazioni distribuite.

Un'altra possibile spiegazione è per le persone che pensano matematicamente. Ogni applicazione è fondamentalmente una macchina a stati con azioni di logica aziendale che sono transizioni di stato. L'idea di REST è di mappare ogni transizione su una richiesta a una risorsa e fornire ai client collegamenti che rappresentano le transizioni disponibili nello stato corrente. Quindi modella la macchina a stati tramite rappresentazioni e collegamenti. Questo è il motivo per cui si chiama REpresentational State Transfer.

È abbastanza sorprendente che tutte le risposte sembrano concentrarsi sul formato dei messaggi o sull'uso dei verbi HTTP. In effetti, il formato del messaggio non ha alcuna importanza, REST può utilizzare chiunque purché lo sviluppatore del servizio lo documenti. I verbi HTTP rendono un servizio solo un servizio CRUD, ma non ancora RESTful. Ciò che trasforma davvero un servizio in un servizio REST sono i collegamenti ipertestuali (noti anche come controlli ipermediali) incorporati nelle risposte del server insieme ai dati e il loro importo deve essere sufficiente affinché qualsiasi client scelga l'azione successiva da quei collegamenti.

Sfortunatamente, è piuttosto difficile trovare informazioni corrette su REST sul Web, ad eccezione della tesi di Roy Fielding . (È colui che ha derivato REST). Consiglierei il libro "REST in Practice" in quanto fornisce un tutorial dettagliato passo-passo su come passare da SOAP a REST.

SAPONE

Questa è una delle possibili forme di architettura RPC (chiamata di procedura remota). In sostanza, è solo una tecnologia che consente ai client di chiamare i metodi del server tramite i confini del servizio (rete, processi, ecc.) Come se stessero chiamando metodi locali. Naturalmente, in realtà differisce dal chiamare metodi locali in velocità, affidabilità e così via, ma l'idea è così semplice.

Rispetto

I dettagli come i protocolli di trasporto, i formati dei messaggi, xsd, wsdl, ecc. Non contano quando si confronta qualsiasi forma di RPC con REST. La differenza principale è che un servizio RPC reinventa la bicicletta progettando il proprio protocollo di applicazione nell'API RPC con la semantica che solo lui conosce. Pertanto, tutti i client devono comprendere questo protocollo prima di utilizzare il servizio e nessuna infrastruttura generica come le cache può essere costruita a causa della semantica proprietaria di tutte le richieste. Inoltre, le API RPC non suggeriscono quali azioni sono consentite nello stato corrente, questo deve essere derivato da ulteriore documentazione. REST implica invece l'uso di interfacce uniformi per consentire a vari client di avere una certa conoscenza della semantica dell'API e controlli ipertestuali (collegamenti) per evidenziare le opzioni disponibili in ogni stato. Così,

In un certo senso, SOAP (come qualsiasi altro RPC) è un tentativo di scavalcare un confine di servizio trattando il supporto di connessione come una scatola nera in grado di trasmettere solo messaggi. REST è una decisione per riconoscere che il Web è un enorme sistema informativo distribuito, per accettare il mondo così com'è e imparare a dominarlo invece di lottare contro di esso.

SOAP sembra essere ottimo per le API di rete interne, quando controlli sia il server che i client e mentre le interazioni non sono troppo complesse. È più naturale per gli sviluppatori utilizzarlo. Tuttavia, per un'API pubblica utilizzata da molte parti indipendenti, è complessa e di grandi dimensioni, REST dovrebbe adattarsi meglio. Ma quest'ultimo confronto è molto confuso.

Aggiornare

La mia esperienza ha inaspettatamente dimostrato che lo sviluppo REST è più difficile di SOAP. Almeno per .NET. Sebbene esistano ottimi framework come l'API Web ASP.NET, non esistono strumenti che generino automaticamente proxy sul lato client. Niente come "Aggiungi riferimento al servizio Web" o "Aggiungi riferimento al servizio WCF". Bisogna scrivere a mano tutto il codice di interrogazione della serializzazione e del servizio. E amico, questo è un sacco di codice per la caldaia Penso che lo sviluppo REST abbia bisogno di qualcosa di simile a WSDL e di implementazione degli strumenti per ogni piattaforma di sviluppo. In effetti, sembra esserci una buona base: WADL o WSDL 2.0 , ma nessuno degli standard sembra essere ben supportato.

Aggiornamento (gennaio 2016)

Si scopre che ora esiste una vasta gamma di strumenti per la definizione dell'API REST. La mia preferenza personale è attualmente RAML .

Come funzionano i servizi Web

Bene, questa è una domanda troppo ampia, perché dipende dall'architettura e dalla tecnologia utilizzate nello specifico servizio web. Ma in generale, un servizio Web è semplicemente un'applicazione nel Web che può accettare richieste dai clienti e restituire risposte. È esposto al Web, quindi è un servizio Web ed è in genere disponibile 24 ore su 24, 7 giorni su 7, per questo è un servizio . Naturalmente, risolve alcuni problemi (altrimenti perché qualcuno dovrebbe mai usare un servizio web) per i suoi clienti.

Questa è la spiegazione più semplice che tu abbia mai trovato.

Questo articolo porta la narrativa da marito a moglie, dove il marito spiega a sua moglie riguardo al RESTO, in termini puramente profani. Devi leggere!

come-ho-spiegato-resto-a-mia-moglie (link originale)
come-ho-spiegato-resto-a-mia-moglie (collegamento di lavoro 2013-07-19)

SOAP - Simple Object Access Protocol è un protocollo !

REST - Il trasferimento di stato rappresentativo è uno stile architettonico !

SOAP è un protocollo XML utilizzato per trasferire messaggi, in genere su HTTP

RESTe SOAPsono probabilmente non escludono a vicenda. Un'architettura RESTful potrebbe usare HTTPo SOAPo qualche altro protocollo di comunicazione. RESTè ottimizzato per il web ed HTTPè quindi una scelta perfetta. HTTPè anche l' unico protocollo discusso nel documento di Roy Fielding.

Sebbene REST e SOAP siano chiaramente molto diversi, la domanda chiarisce il fatto che RESTe HTTPsono spesso usati in tandem. Ciò è dovuto principalmente alla semplicità di HTTP e alla sua mappatura molto naturale ai principi RESTful.

Principi fondamentali di REST

Comunicazione client-server

Le architetture client-server hanno una netta separazione di preoccupazioni. Tutte le applicazioni costruite in stile RESTful devono anche essere client-server in linea di principio.

apolide

Ogni richiesta di ogni client al server richiede che il suo stato sia completamente rappresentato. Il server deve essere in grado di comprendere completamente la richiesta del client senza utilizzare alcun contesto o stato della sessione del server. Ne consegue che tutto lo stato deve essere mantenuto sul client. Discuteremo la rappresentazione senza stato in modo più dettagliato in seguito.

cacheable

È possibile utilizzare i vincoli della cache, consentendo così di contrassegnare i dati di risposta come memorizzabili nella cache o non memorizzabili nella cache. Tutti i dati contrassegnati come memorizzabili nella cache possono essere riutilizzati come risposta alla stessa richiesta successiva.

Interfaccia uniforme

Tutti i componenti devono interagire attraverso un'unica interfaccia uniforme. Poiché tutte le interazioni tra componenti si verificano tramite questa interfaccia, l'interazione con servizi diversi è molto semplice. L'interfaccia è la stessa! Questo significa anche che le modifiche all'implementazione possono essere fatte isolatamente. Tali modifiche non influiranno sull'interazione dei componenti fondamentali poiché l'interfaccia uniforme è sempre invariata. Uno svantaggio è che sei bloccato con l'interfaccia. Se è possibile fornire un'ottimizzazione a un servizio specifico modificando l'interfaccia, si è sfortunati poiché REST lo proibisce. Il lato positivo, tuttavia, REST è ottimizzato per il web, quindi incredibile popolarità di REST su HTTP!

I concetti di cui sopra rappresentano le caratteristiche distintive di REST e differenziano l'architettura REST da altre architetture come i servizi web. È utile notare che un servizio REST è un servizio Web, ma un servizio Web non è necessariamente un servizio REST.

Vedi questo post sul blog su REST Design Principals per maggiori dettagli su REST e i punti elenco sopra indicati.

Mi piace la risposta di Brian R. Bondy. Volevo solo aggiungere che Wikipedia fornisce una chiara descrizione di REST . L'articolo lo distingue da SOAP.

REST è uno scambio di informazioni statali, fatto nel modo più semplice possibile.

SOAP è un protocollo di messaggio che utilizza XML.

Uno dei motivi principali per cui molte persone sono passate da SOAP a REST è che gli standard WS- * (chiamati WS splat) associati ai servizi web basati su SOAP sono ESTREMAMENTE complicati. Vedi Wikipedia per un elenco delle specifiche. Ognuna di queste specifiche è molto complicata.

EDIT: per qualche motivo i collegamenti non vengono visualizzati correttamente. REST = http://it.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

Sia i servizi Web SOAP che i servizi Web REST possono utilizzare anche il protocollo HTTP e altri protocolli (solo per citare SOAP può essere il protocollo sottostante di REST). Parlerò solo del protocollo HTTP SOAP e REST, perché questo è il loro utilizzo più frequente.

SAPONE

SOAP ("semplice" protocollo di accesso agli oggetti) è un protocollo (e uno standard W3C ). Definisce come creare, inviare ed elaborare messaggi SOAP.

• I messaggi SOAP sono documenti XML con una struttura specifica: contengono una busta che contiene l'intestazione e la sezione del corpo. Il corpo contiene i dati effettivi, che vogliamo inviare, in un formato XML. Esistono due stili di codifica , ma di solito scegliamo letteralmente , il che significa che la nostra applicazione o il suo driver SOAP esegue la serializzazione XML e la non serializzazione dei dati.

• I messaggi SOAP viaggiano come messaggi HTTP con sottotipo MIME SOAP + XML. Questi messaggi HTTP possono essere multipart, quindi facoltativamente possiamo allegare file ai messaggi SOAP.

• Ovviamente utilizziamo un'architettura client-server, quindi i client SOAP inviano richieste ai webserice SOAP e i servizi inviano risposte ai client. La maggior parte dei servizi Web utilizza un file WSDL per descrivere il servizio. Il file WSDL contiene lo schema XML (di seguito XSD) dei dati che vogliamo inviare e l'associazione WSDL che definisce come il servizio web è legato al protocollo HTTP. Esistono due stili di rilegatura: RPC e documento. Con l'associazione di stile RPC il corpo SOAP contiene la rappresentazione di una chiamata di operazione con i parametri (richieste HTTP) o i valori di ritorno (risposta HTTP). I parametri e i valori di ritorno sono convalidati rispetto all'XSD. In base allo stile del documento, il corpo SOAP contiene un documento XML convalidato rispetto all'XSD. Penso che lo stile di rilegatura del documento sia più adatto ai sistemi basati su eventi, ma non ho mai usato quello stile di rilegatura. Lo stile di associazione RPC è più diffuso, quindi la maggior parte delle persone usa SOAP per scopi XML / RPC da applicazioni distribuite. I servizi web di solito si trovano l'un l'altro chiedendo a un server UDDI . I server UDDI sono registri che memorizzano la posizione dei servizi web.

SAPONE RPC

Quindi, secondo me, il servizio web SOAP più diffuso utilizza lo stile di rilegatura RPC e lo stile di codifica letterale e ha le seguenti proprietà:

• Associa gli URL alle operazioni.
• Invia messaggi con sottotipo MIME SOAP + XML.
• Può avere un archivio di sessioni lato server, non ci sono vincoli al riguardo.
• I driver client SOAP utilizzano il file WSDL del servizio per convertire le operazioni RPC in metodi. L'applicazione lato client comunica con il servizio Web SOAP chiamando questi metodi. Pertanto, la maggior parte dei client SOAP interrompe le modifiche all'interfaccia (risultanti nomi dei metodi e / o modifiche ai parametri).
• È possibile scrivere client SOAP che non si rompono con i cambiamenti di interfaccia usando RDF e trovare operazioni tramite semantica, ma i servizi web semantici sono molto rari e non hanno necessariamente un client non break (suppongo).

RIPOSO

REST (rappresentational state transfer) è uno stile architettonico descritto nella tesi di laurea di Roy Fielding. Non riguarda i protocolli come SOAP. Si inizia con uno stile di architettura null senza vincoli e definisce i vincoli dell'architettura REST uno per uno. Le persone usano il termine RESTful per servizi web che soddisfano tutti i vincoli REST, ma secondo Roy Fielding, non ci sono cose come i livelli REST . Quando un servizio Web non soddisfa tutti i vincoli REST, non è un servizio Web REST.

Vincoli REST

• Architettura client - server - Penso che questa parte sia familiare a tutti. I client REST comunicano con i servizi Web REST, i servizi Web mantengono i dati comuni - lo stato delle risorse di seguito - e li forniscono ai client.
• Stateless - La parte "trasferimento di stato" dell'abbreviazione: REST. I client mantengono lo stato client (stato sessione / applicazione), quindi i servizi non devono avere un archivio sessioni. I client trasferiscono la parte rilevante dello stato client da ogni richiesta ai servizi che rispondono con la parte rilevante dello stato della risorsa (gestita da essi). Quindi le richieste non hanno contesto, contengono sempre le informazioni necessarie per elaborarle. Ad esempio, tramite l'autenticazione di base HTTP, il nome utente e la password vengono memorizzati dal client e li invia con ogni richiesta, quindi l'autenticazione avviene per ogni richiesta. Questo è molto diverso dalle normali applicazioni web in cui l'autenticazione avviene solo tramite login. Possiamo utilizzare qualsiasi meccanismo di archiviazione dei dati lato client come in memoria (javascript), cookie, localStorage e così via ... persistere in alcune parti dello stato del client, se lo desideriamo. La ragione del vincolo di apolidia, che il server si adatta bene - anche con un carico molto elevato (milioni di utenti) - quando non deve mantenere la sessione di ogni singolo client.
• Cache: la risposta deve contenere informazioni che possono essere memorizzate nella cache dal client o meno. Ciò migliora ulteriormente la scalabilità.

• Interfaccia uniforme

  • Identificazione delle risorse - La risorsa REST è uguale alla risorsa RDF . Secondo Fielding se puoi nominare qualcosa, allora può essere una risorsa, ad esempio: "il tempo locale attuale" può essere una risorsa, oppure "il tuo cellulare" può essere una risorsa o "un documento Web specifico" può essere una risorsa. Per identificare una risorsa è possibile utilizzare identificatori di risorse: URL e URN (ad esempio il numero ISBN di libri ). Un singolo identificatore dovrebbe appartenere solo a una risorsa specifica, ma una singola risorsa può avere molti identificatori, che spesso sfruttiamo ad esempio impaginando con URL simili https://example.com/api/v1/users?offset=50&count=25. Gli URL hanno alcune specifiche, ad esempio URL con gli stessi percorsi ma query diverse non sono identiche oppure la parte del percorso deve contenere i dati gerarchici dell'URL e la parte della query deve contenere i dati non gerarchici. Queste sono le basi di come creare URL tramite REST. Btw. la struttura dell'URL è importante solo per gli sviluppatori di servizi, un vero client REST non se ne occupa. Un'altra domanda frequente è il versioning delle API, che è facile, perché secondo Fielding l'unica cosa costante per risorsa è la semantica. Se la semantica cambia, è possibile aggiungere un nuovo numero di versione. Puoi utilizzare il classico versioning a 3 numeri e aggiungere solo il numero principale agli URL (https://example.com/api/v1/). Quindi, con modifiche compatibili con le versioni precedenti non accade nulla, con modifiche compatibili con le versioni precedenti avrai una semantica compatibile con le versioni precedenti con una nuova radice API https://example.com/api/v2/. Quindi i vecchi client non si romperanno, perché possono usare il https://example.com/api/v1/con la vecchia semantica.
  • Manipolazione delle risorse tramite rappresentazioni: è possibile manipolare i dati relativi alle risorse (stato delle risorse) inviando la rappresentazione prevista delle risorse, insieme al metodo HTTP e all'identificatore delle risorse, al servizio REST. Ad esempio, se si desidera rinominare un utente dopo il matrimonio, è possibile inviare una PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}richiesta in cui {name: "Mrs Smith"}è una rappresentazione JSON dello stato della risorsa previsto, in altre parole: il nuovo nome. Questo accade viceversa, il servizio invia rappresentazioni di risorse ai client per cambiare i loro stati. Ad esempio, se vogliamo leggere il nuovo nome, possiamo inviare una GET https://example.com/api/v1/users/1?fields="name"richiesta di recupero, che si traduce in a200 ok, {name: "Mrs Smith"}risposta. Quindi possiamo usare questa rappresentazione per cambiare lo stato del cliente, ad esempio possiamo mostrare un "Benvenuto nella nostra pagina Mrs Smith!" Messaggio. Una risorsa può avere molte rappresentazioni a seconda dell'identificatore di risorsa (URL) o acceptdell'intestazione che abbiamo inviato con la richiesta. Ad esempio, se richiesto, possiamo inviare un'immagine della signora Smith (probabilmente non nuda) image/jpeg.
  • Messaggi auto-descrittivi: i messaggi devono contenere informazioni su come elaborarli. Ad esempio metodo URI e HTTP, intestazione del tipo di contenuto, intestazioni della cache, RDF che descrive il significato dei dati, ecc. È importante utilizzare metodi standard. È importante conoscere le specifiche dei metodi HTTP. Ad esempio GET significa recuperare informazioni identificate dall'URL di richiesta, DELETE significa chiedere al server di eliminare la risorsa identificata dall'URL specificato e così via ... Anche i codici di stato HTTP hanno una specifica , ad esempio 200 significa successo, 201 significa una nuova risorsa è stata creata, 404 significa che la risorsa richiesta non è stata trovata sul server, ecc. L'uso degli standard esistenti è una parte importante di REST.

  • Hypermedia come motore dello stato dell'applicazione (di seguito HATEOAS) - Hypermedia è un tipo di supporto che può contenere collegamenti ipertestuali. Dal web seguiamo i link - descritti da un formato hypermedia (di solito HTML) - per raggiungere un obiettivo, invece di digitare gli URL nella barra degli indirizzi. REST segue lo stesso concetto, le rappresentazioni inviate dal servizio possono contenere collegamenti ipertestuali. Utilizziamo questi collegamenti ipertestuali per inviare richieste al servizio. Con la risposta otteniamo dati (e probabilmente più collegamenti) che possiamo usare per costruire il nuovo stato client, e così via ... Ecco perché hypermedia è il motore dello stato dell'applicazione (stato client). Probabilmente ti chiedi come fanno i clienti a riconoscere e seguire i collegamenti ipertestuali? Per gli umani è abbastanza semplice, leggiamo il titolo del link, forse riempiamo i campi di input e dopo un solo clic.JSON-LD con Hydra ) o con soluzioni specifiche ipermediali (ad esempio relazioni di collegamento IANA e tipi MIME specifici del fornitore di HAL + JSON ). Esistono molti formati XML e JSON hypermedia leggibili da una macchina , solo un breve elenco di essi:

    • XHTML
    • ATOM + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • Sirena
    • Collezione + JSON

    A volte è difficile scegliere ...

• Sistema a più livelli: possiamo utilizzare più livelli tra i client e i servizi. Nessuno di loro dovrebbe sapere di tutti questi livelli addizionali, solo del livello proprio accanto ad esso. Questi livelli possono migliorare la scalabilità applicando cache e bilanciamento del carico oppure possono applicare criteri di sicurezza.
• Codice su richiesta: siamo in grado di inviare indietro il codice che estende la funzionalità del client, ad esempio il codice javascript a un browser. Questo è l'unico vincolo opzionale di REST.

Servizio web REST - Differenze del servizio web RPC SOAP

Quindi un servizio web REST è molto diverso da un servizio web SOAP (con stile di rilegatura RPC e stile di codifica letterale)

• Definisce un'interfaccia uniforme (intead di un protocollo).
• Associa gli URL alle risorse (e non alle operazioni).
• Invia messaggi con qualsiasi tipo MIME (anziché solo SOAP + XML).
• Ha una comunicazione senza stato e quindi non può avere un archivio di sessioni lato server. (SOAP non ha alcun vincolo al riguardo)
• Serve hypermedia e i client utilizzano i collegamenti contenuti da quell'hypermedia per richiedere il servizio. (SOAP RPC utilizza i collegamenti alle operazioni descritti nel file WSDL)
• Non si interrompe per le modifiche all'URL solo per le modifiche semantiche. (I client RAP SOAP senza utilizzare la semantica RDF interrompono le modifiche al file WSDL.)
• Ridimensiona meglio di un servizio web SOAP a causa del suo comportamento senza stato.

e così via...

Un servizio web RPC SOAP non soddisfa tutti i vincoli REST:

• architettura client-server - sempre
• apolide - possibile
• cache - possibile
• interfaccia uniforme - mai
• sistema a strati - mai
• codice su richiesta (opzionale) - possibile

Bene, inizierò con la seconda domanda: che cosa sono i servizi Web? , per ovvie ragioni.

I servizi Web sono essenzialmente elementi logici (a cui si può vagamente fare riferimento come metodo) che espongono determinate funzionalità o dati. Il client che implementa (tecnicamente parlando, consumare è la parola) deve solo sapere quali sono i parametri che il metodo accetterà e il tipo di dati che restituirà (se non del tutto).

Il seguente link dice tutto su REST & SOAP in un modo estremamente lucido.

REST vs SOAP

Se vuoi anche sapere quando scegliere cosa (RIPOSO o SAPONE), motivo in più per affrontarlo!

SOAP e REST si riferiscono entrambi ai modi in cui diversi sistemi possono dialogare.

REST fa questo usando tecniche che assomigliano alla comunicazione che il tuo browser ha con i web server: usando GET per richiedere una pagina web, POST nei campi modulo, ecc.

SOAP fornisce qualcosa di simile ma fa tutto attraverso l'invio di blocchi di XML avanti e indietro. Un altro componente chiave di SOAP è WSDL che è un documento XML che descrive quali funzioni ed elementi di dati sono supportati. I WSDL possono essere utilizzati per "scoprire" a livello di programmazione quali funzioni sono supportate, nonché per generare stub di codice di programmazione.

Penso che sia facile come posso spiegarlo. Per favore, chiunque è il benvenuto per correggermi o aggiungere a questo.

SOAP è un formato di messaggio utilizzato da sistemi disconnessi (come su Internet) per scambiare informazioni / dati. Lo fa con i messaggi XML che vanno avanti e indietro.

I servizi Web trasmettono o ricevono messaggi SOAP. Funzionano in modo diverso a seconda della lingua in cui sono scritti.

Il problema con SOAP è che è in conflitto con gli ideali dietro lo stack HTTP. Qualsiasi middleware dovrebbe essere in grado di funzionare con le richieste HTTP senza comprendere il contenuto della richiesta o della risposta, ma ad esempio un normale server di cache HTTP non funzionerà con le richieste SOAP senza conoscere solo quali parti del contenuto SOAP sono importanti per la memorizzazione nella cache. SOAP utilizza HTTP come wrapper per il proprio protocollo di comunicazione, come un proxy.

REST è uno stile di architettura per la progettazione di applicazioni in rete. L'idea è che, anziché utilizzare meccanismi complessi come CORBA, RPC o SOAP per connettersi tra macchine, viene utilizzato HTTP semplice per effettuare chiamate tra macchine.

SOAP - "Simple Object Access Protocol"

SOAP è una sorta di trasferimento di messaggi o piccole quantità di informazioni su Internet. I messaggi SOAP sono formattati in XML e in genere vengono inviati controllando HTTP .

REST - "Trasferimento di stato rappresentativo"

REST è un rudimentale procedimento di eventualità e ricezione di informazioni tra fan e server e non ha inequivocabilmente definito molti standard. È possibile inviare e accettare informazioni come JSON , XML o persino testo semplice. È leggero rispetto al sapone .

Servizi Web basati su SOAP In breve, il modello dei servizi basati su SOAP vede il mondo come un ecosistema di pari pari che non possono controllarsi a vicenda, ma devono lavorare insieme onorando i contratti pubblicati. È un modello valido del disordinato mondo reale e i contratti basati sui metadati formano l'interfaccia di servizio SOAP.

possiamo ancora associare SOAP a chiamate di procedura remota basate su XML, ma la tecnologia dei servizi Web basata su SOAP è emersa in un modello di messaggistica flessibile e potente.

SOAP presuppone che tutti i sistemi siano indipendenti e nessun sistema abbia alcuna conoscenza degli interni di un'altra funzionalità interna. Il massimo che tali sistemi possono fare è inviare messaggi l'uno all'altro e sperare che vengano attuati. I sistemi pubblicano contratti che si impegnano a onorare e altri sistemi si affidano a questi contratti per scambiare messaggi con loro.

I contratti tra i sistemi sono chiamati collettivamente metadati e comprendono descrizioni dei servizi, i modelli di scambio di messaggi supportati e le politiche che regolano le qualità del servizio (potrebbe essere necessario crittografare un servizio, consegnarlo in modo affidabile, ecc.) Una descrizione del servizio, a sua volta, è un dettaglio specifica dei dati (documenti di messaggio) che verranno inviati e ricevuti dal sistema. I documenti sono descritti usando un linguaggio di descrizione XML come XML Schema Definition. Fino a quando tutti i sistemi rispettano i loro contratti pubblicati, possono interagire e le modifiche interne ai sistemi non influiscono mai su nessun altro. Ogni sistema è responsabile della traduzione delle proprie implementazioni interne da e verso i suoi contratti

REST - Trasferimento di stato rappresentativo. Il protocollo fisico è HTTP. Fondamentalmente, REST è che tutte le risorse distinte sul web che sono identificabili in modo univoco da un URL. Tutte le operazioni che possono essere eseguite su queste risorse possono essere descritte da un insieme limitato di verbi (i verbi "CRUD") che a loro volta si associano ai verbi HTTP.

REST è molto meno "pesante" rispetto a SAPONE.

Funzionamento del servizio web