web-services - sono - web api soap




SOAP vs REST(differenze) (8)

Ho letto articoli sulle differenze tra SOAP e REST come protocollo di comunicazione di servizi Web, ma penso che i maggiori vantaggi di REST su SOAP siano:

  1. REST è più dinamico, non è necessario creare e aggiornare UDDI.

  2. REST non è limitato al formato XML. I servizi Web REST possono inviare testo in chiaro, JSON e anche XML.

Ma SOAP è più standardizzato (Ex, sicurezza).

Quindi, ho ragione in questi punti?


Aggiunta per:

++ Un errore che viene spesso commesso quando ci si avvicina a REST è di considerarlo come "servizi Web con URL" - pensare a REST come un altro meccanismo di chiamata a procedura remota (RPC), come SOAP, ma invocato tramite URL HTTP semplici e senza SOAP Spazi dei nomi XML.

++ Al contrario, REST ha poco a che fare con RPC. Mentre RPC è orientato al servizio e focalizzato su azioni e verbi, il REST è orientato alle risorse, sottolineando le cose e i nomi che costituiscono un'applicazione.


Differenza tra riposo e sapone

SAPONE

  1. SOAP è un protocollo.
  2. SOAP sta per Simple Object Access Protocol.
  3. SOAP non può usare REST perché è un protocollo.
  4. SOAP utilizza le interfacce di servizi per esporre la logica aziendale.
  5. SOAP definisce gli standard da seguire rigorosamente.
  6. SOAP richiede più larghezza di banda e risorse rispetto a REST.
  7. SOAP definisce la propria sicurezza.
  8. SOAP consente solo il formato dati XML.
  9. SOAP è meno preferito di REST.

RIPOSO

  1. REST è uno stile architettonico.
  2. REST sta per Representational State Transfer.
  3. REST può utilizzare i servizi Web SOAP perché è un concetto e può utilizzare qualsiasi protocollo come HTTP, SOAP.
  4. REST utilizza l'URI per esporre la logica di business.
  5. REST non definisce troppo standard come SOAP.
  6. REST richiede meno larghezza di banda e risorse di SOAP.
  7. I servizi web RESTful ereditano le misure di sicurezza dal trasporto sottostante.
  8. REST consente diversi formati di dati come testo normale, HTML, XML, JSON, ecc.
  9. REST più preferito di SOAP.

Per maggiori dettagli si prega di vedere here


La decisione tra i due sarà la tua prima scelta nella progettazione di un servizio web, quindi è importante capire i pro ei contro dei due. È anche importante, nel dibattito a volte acceso tra le due filosofie, separare la realtà dalla retorica.

Fondamenti di REST

  • Tutto in REST è considerato una risorsa.
  • Ogni risorsa è identificata da un URI.
  • Utilizza interfacce uniformi. Le risorse vengono gestite utilizzando le operazioni POST, GET, PUT, DELETE che sono simili alle operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD).
  • Essere apolidi. Ogni richiesta è una richiesta indipendente. Ogni richiesta dal client al server deve contenere tutte le informazioni necessarie per comprendere la richiesta.
  • Le comunicazioni sono fatte tramite rappresentazioni. Ad esempio, XML, JSON RESTful Web Services. I servizi web RESTful sono basati su metodi HTTP e sul concetto di REST. Un servizio web RESTful in genere definisce l'URI di base per i servizi; i tipi MIME supportati (XML, testo, JSON, definito dall'utente, ...) e il set di operazioni (POST, GET, PUT, DELETE) supportati.

Fondamenti di SOAP

  • WSDL definisce il contratto tra cliente e servizio ed è statico per sua natura.
  • SOAP crea un protocollo basato su XML su HTTP o talvolta su TCP / IP.
  • SOAP descrive funzioni e tipi di dati.
  • SOAP è un successore di XML-RPC ed è molto simile, ma descrive un modo standard per comunicare.
  • Diversi linguaggi di programmazione hanno il supporto nativo per SOAP, in genere gli si fornisce un URL di servizio Web e si possono chiamare le sue funzioni di 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 relativi: WSDL, XSD, SOAP, indirizzamento WS.

SOAP vs REST?

Uno dei principali vantaggi di SOAP è la presenza di una descrizione del servizio WSDL. Puoi praticamente scoprire il servizio automaticamente e generare un proxy client utilizzabile da quella descrizione del servizio (generare le chiamate di servizio, i tipi di dati necessari per i metodi e così via). Si noti che con la versione 2.0, WSDL supporta tutti i verbi HTTP e può essere utilizzato anche per documentare i servizi RESTful, ma a tale scopo esiste un'alternativa meno dettagliata in WADL (Web Application Description Language).

Con i servizi RESTful, la sicurezza dei messaggi è fornita dal protocollo di trasporto (HTTPS) ed è solo punto-punto. Non ha un sistema di messaggistica standard e si aspetta che i clienti si occupino dei problemi di comunicazione riprovando. SOAP ha una logica di successo / retry integrata e fornisce un'affidabilità end-to-end anche attraverso gli intermediari SOAP.

Uno dei principali vantaggi dell'API RESTful è che è flessibile per la rappresentazione dei dati, ad esempio è possibile serializzare i dati in formato XML o JSON. Le API RESTful sono più pulite o più facili da capire perché aggiungono un elemento dell'utilizzo di URI standardizzati e danno importanza al verbo HTTP utilizzato (ad esempio, GET, POST, PUT e DELETE).

I servizi RESTful sono anche leggeri, cioè non hanno molti markup XML extra. Per invocare l'API RESTful tutto ciò di cui hai bisogno è un browser o uno stack HTTP e praticamente ogni dispositivo o macchina connessa a una rete ce l'ha.

Vantaggi del REST

  • Poiché REST utilizza HTTP standard, è molto più semplice in quasi tutti i modi. Creare clienti, sviluppare API, la documentazione è molto più facile da capire, e non ci sono molte cose che REST non fa più facile / meglio di SOAP.
  • REST consente molti formati di dati diversi mentre SOAP consente solo XML. Mentre questo può sembrare che aggiunge complessità a REST perché è necessario gestire più formati, nella mia esperienza, è stato molto utile. Di solito, JSON è più adatto per i dati e le analisi molto più velocemente. REST consente un miglior supporto per i client browser grazie al supporto per JSON.
  • REST ha prestazioni e scalabilità migliori. Le letture REST possono essere memorizzate nella cache; Le letture basate su SOAP non possono essere memorizzate nella cache.
  • Nessun costoso strumento richiede l'interazione con il servizio Web
  • Curva di apprendimento più piccola
  • Efficiente (SOAP utilizza l'XML per tutti i messaggi, REST può usare formati di messaggio più piccoli)
  • Veloce (non è richiesta un'elaborazione estesa)
  • Più vicino ad altre tecnologie Web nella filosofia del design

Vantaggi del sapone

  • WS-Security: Mentre SOAP supporta SSL (proprio come REST), supporta anche WS-Security che aggiunge alcune funzionalità di sicurezza aziendale. Supporta l'identità tramite intermediari, non solo punto a punto (SSL). Fornisce inoltre un'implementazione standard dell'integrità dei dati e della riservatezza dei dati. Chiamarlo "Enterprise" non vuol dire che sia più sicuro, semplicemente supporta alcuni strumenti di sicurezza di cui non sono necessari i tipici servizi Internet, in realtà sono necessari solo in alcuni scenari "enterprise".
  • WS-AtomicTransaction: occorrono transazioni ACID su un servizio, hai bisogno di SOAP. Mentre REST supporta le transazioni, non è così completo e non è compatibile con ACID. Fortunatamente, le transazioni ACID non hanno quasi mai senso su Internet. REST è limitato da HTTP stesso che non può fornire commit a due fasi su risorse transazionali distribuite, ma SOAP può. Le app Internet non hanno bisogno di questo livello di affidabilità della transazione, a volte le app aziendali lo fanno.
  • WS-ReliableMessaging: Rest non ha un sistema di messaggistica standard e si aspetta che i client affrontino i problemi di comunicazione riprovando. SOAP ha una logica di successo / retry integrata e fornisce un'affidabilità end-to-end anche attraverso gli intermediari SOAP.
  • Lingua, piattaforma e trasporto indipendenti (REST richiede l'uso di HTTP)
  • Funziona bene in ambienti aziendali distribuiti (REST si basa sulla comunicazione diretta punto-punto)
  • standardizzato
  • Fornisce una notevole estensibilità pre-build sotto forma di standard WS
  • Gestione degli errori integrata
  • Automazione se utilizzata con determinati prodotti linguistici

Dove usare REST

le aree in cui REST funziona bene sono:

  • Larghezza di banda e risorse limitate: ricorda che la struttura di ritorno è veramente in qualsiasi formato (definito dallo sviluppatore). Inoltre, è possibile utilizzare qualsiasi browser perché l'approccio REST utilizza i verbi GET, PUT, POST e DELETE standard. Ancora una volta, ricorda che REST può anche utilizzare l'oggetto XMLHttpRequest supportato oggi dalla maggior parte dei browser moderni, che aggiunge un bonus di AJAX.
  • operazioni senza stato: se è necessario continuare un'operazione, REST non è l'approccio migliore e SOAP può adattarlo meglio. Tuttavia, se hai bisogno di operazioni CRUD (Crea, Leggi, Aggiorna ed Elimina) stateless, allora REST è.
  • Situazioni di caching: se le informazioni possono essere memorizzate nella cache a causa dell'operazione stateless dell'approccio REST, ciò è perfetto.

Dove usare SOAP

aree in cui SOAP funziona come una grande soluzione:

  • Elaborazione asincrona e invocazione: se l'applicazione richiede un livello di affidabilità e sicurezza garantiti, SOAP 1.2 offre ulteriori standard per garantire questo tipo di operazione. Cose come WSRM - WS-Reliable Messaging.
  • Contratti formali: se entrambe le parti (fornitore e consumatore) devono concordare il formato di scambio, SOAP 1.2 fornisce le rigide specifiche per questo tipo di interazione.
  • Operazioni stateful: se l'applicazione necessita di informazioni contestuali e di gestione dello stato conversazionale, SOAP 1.2 dispone delle specifiche aggiuntive nella struttura WS per supportare tali elementi (Sicurezza, Transazioni, Coordinamento, ecc.). Comparativamente, l'approccio REST farà sì che gli sviluppatori costruiscano questo impianto idraulico personalizzato.

Molte di queste risposte hanno completamente dimenticato di menzionare i controlli hypermedia (HATEOAS), che sono assolutamente fondamentali per REST. Alcuni altri lo hanno toccato, ma in realtà non lo hanno spiegato molto bene.

Questo articolo dovrebbe spiegare la differenza tra i concetti, senza entrare nelle erbacce su specifiche funzionalità SOAP.


SOAP ( Simple Object Access Protocol ) e REST ( Representation State Transfer ) sono entrambi a loro modo. Quindi non li sto confrontando. Invece, sto cercando di descrivere l'immagine, quando ho preferito usare REST e quando SOAP.

Cos'è il carico utile?

Quando i dati vengono inviati su Internet, ogni unità trasmessa include sia le informazioni di intestazione che i dati effettivi inviati. L'intestazione identifica l'origine e la destinazione del pacchetto, mentre i dati effettivi vengono definiti payload . In generale, il carico utile è il dato trasportato per conto di un'applicazione e i dati ricevuti dal sistema di destinazione.

Ora, per esempio, devo inviare un telegramma e sappiamo tutti che il costo del telegramma dipenderà da alcune parole.

Allora, dimmi tra i seguenti due messaggi, quale è più economico da inviare?

<name>Arin</name>

o

"name": "Arin"

So che la tua risposta sarà la seconda, sebbene entrambe rappresentino lo stesso messaggio la seconda è più economica in termini di costi.

Quindi sto cercando di dire che, l' invio di dati attraverso la rete in formato JSON è più economico rispetto all'invio in formato XML per quanto riguarda il carico utile .

Ecco il primo vantaggio o vantaggi di REST su SOAP . SOAP supporta solo XML, ma REST supporta diversi formati come testo, JSON, XML, ecc. E sappiamo già, se usiamo Json, sicuramente saremo in una posizione migliore per quanto riguarda il carico utile.

Ora, SOAP supporta l'unico XML, ma ha anche i suoi vantaggi.

Veramente! Come?

SOAP si basa su XML in tre modi Envelope - che definisce cosa c'è nel messaggio e come elaborarlo.

Una serie di regole di codifica per i tipi di dati e infine il layout delle chiamate di procedura e le risposte raccolte.

Questa busta viene inviata tramite un trasporto (HTTP / HTTPS) e viene eseguito un RPC (Remote Procedure Call) e la busta viene restituita con informazioni in un documento formattato XML.

Il punto importante è che uno dei vantaggi di SOAP è l'uso del trasporto "generico" ma REST utilizza HTTP / HTTPS . SOAP può utilizzare quasi tutti i trasporti per inviare la richiesta ma REST non può. Quindi qui abbiamo il vantaggio di usare SOAP.

Come ho già detto nel precedente paragrafo "REST utilizza HTTP / HTTPS" , quindi approfondisci le parole.

Quando parliamo di REST su HTTP, tutte le misure di sicurezza applicate HTTP vengono ereditate e questo è noto come sicurezza del livello di trasporto e protegge i messaggi solo mentre è all'interno del filo, ma una volta che l'hai consegnato dall'altra parte non lo sai quante fasi dovrà attraversare prima di raggiungere il punto reale in cui verranno elaborati i dati. E, naturalmente, tutte quelle fasi potrebbero utilizzare qualcosa di diverso da HTTP. Quindi il riposo non è più sicuro, giusto?

Ma SOAP supporta SSL proprio come REST , inoltre supporta anche WS-Security che aggiunge alcune funzionalità di sicurezza aziendale. WS-Security offre protezione dalla creazione del messaggio al suo consumo . Quindi, per la sicurezza a livello di trasporto, qualunque scappatoia abbiamo trovato che può essere prevenuta usando WS-Security.

A parte questo, poiché REST è limitato dal suo protocollo HTTP, quindi il suo supporto alle transazioni non è né compatibile con ACID né può fornire commit in due fasi tra le risorse transnazionali distribuite.

Ma SOAP ha un supporto completo per la gestione delle transazioni basate su ACID per transazioni di breve durata e la gestione delle transazioni basata sulla compensazione per transazioni di lunga durata. Supporta inoltre il commit a due fasi tra le risorse distribuite .

Non sto tracciando alcuna conclusione, ma preferirò il servizio web basato su SOAP mentre la sicurezza, la transazione, ecc. Sono le preoccupazioni principali.

Ecco il "The Java EE 6 Tutorial" in cui hanno affermato che un design RESTful può essere appropriato quando sono soddisfatte le seguenti condizioni . Dare un'occhiata.

Spero ti sia piaciuto leggere la mia risposta.


Sfortunatamente, ci sono un sacco di disinformazione e idee sbagliate in merito a REST. Non solo la tua domanda e la risposta di @cmd riflettono quelle, ma la maggior parte delle domande e risposte relative all'argomento su .

SOAP e REST non possono essere confrontati direttamente, dal momento che il primo è un protocollo (o almeno tenta di essere) e il secondo è uno stile architettonico. Questa è probabilmente una delle fonti di confusione intorno a questo, dal momento che le persone tendono a chiamare REST qualsiasi API HTTP che non sia SOAP.

Spingendo un po 'le cose e cercando di stabilire un confronto, la principale differenza tra SOAP e REST è il grado di accoppiamento tra implementazioni client e server. Un client SOAP funziona come un'applicazione desktop personalizzata, strettamente accoppiata al server. C'è un contratto rigido tra client e server, e tutto dovrebbe rompersi se una delle parti cambia qualcosa. Hai bisogno di aggiornamenti costanti dopo ogni modifica, ma è più facile accertare se il contratto viene seguito.

Un client REST è più simile a un browser. È un client generico che sa usare un protocollo e metodi standardizzati e un'applicazione deve adattarsi al suo interno. Non violi gli standard del protocollo creando metodi aggiuntivi, fai leva sui metodi standard e crea le azioni con loro sul tuo tipo di media. Se fatto bene, c'è meno accoppiamento e le modifiche possono essere gestite con più grazia. Un client deve immettere un servizio REST con conoscenza zero dell'API, ad eccezione del punto di ingresso e del tipo di supporto. In SOAP, il cliente ha bisogno di conoscenze precedenti su tutto ciò che utilizzerà, o non inizierà nemmeno l'interazione. Inoltre, un client REST può essere esteso dal codice su richiesta fornito dal server stesso, l'esempio classico è il codice JavaScript utilizzato per guidare l'interazione con un altro servizio sul lato client.

Penso che questi siano i punti cruciali per capire di cosa si tratta REST e come si differenzia da SOAP:

  • REST è indipendente dal protocollo. Non è accoppiato a HTTP. Praticamente come se fosse possibile seguire un collegamento ftp su un sito Web, un'applicazione REST può utilizzare qualsiasi protocollo per il quale esiste uno schema URI standardizzato.

  • REST non è una mappatura dei metodi CRUD in HTTP. Leggi this risposta per una spiegazione dettagliata al riguardo.

  • REST è standardizzato come le parti che stai utilizzando. La sicurezza e l'autenticazione in HTTP sono standardizzate, quindi è quello che usi quando esegui REST su HTTP.

  • REST non è REST senza hypermedia e HATEOAS . Ciò significa che un client conosce solo l'URI del punto di ingresso e le risorse dovrebbero restituire i collegamenti che il client dovrebbe seguire. Quei fantasiosi generatori di documentazione che forniscono schemi URI per tutto ciò che puoi fare in un'API REST non riescono a cogliere completamente il punto. Non stanno solo documentando qualcosa che dovrebbe seguire lo standard, ma quando lo fai, stai accoppiando il cliente a un particolare momento nell'evoluzione dell'API, e qualsiasi modifica sull'API deve essere documentata e applicata, o si romperà.

  • REST è lo stile architettonico del web stesso. Quando inserisci , sai cosa sono un utente, una domanda e una risposta, conosci i tipi di media e il sito web ti fornisce i link. Un'API REST deve fare lo stesso. Se abbiamo progettato il web come la gente pensa che REST debba essere fatto, invece di avere una home page con collegamenti a Domande e Risposte, avremmo una documentazione statica che spiega che per poter visualizzare una domanda, devi prendere lo .com/questions/<id> URI .com/questions/<id> , sostituisci id con Question.id e incollalo sul tuo browser. Questa è una sciocchezza, ma è quello che molte persone pensano che sia REST.

Questo ultimo punto non può essere sottolineato abbastanza. Se i tuoi clienti costruiscono URI da modelli nella documentazione e non ottengono collegamenti nelle rappresentazioni di risorse, non è REST. Roy Fielding, l'autore di REST, ha chiarito questo post sul blog: le API REST devono essere guidate da ipertesto .

Tenendo presente quanto sopra, ti renderai conto che mentre REST non può essere limitato a XML, per farlo correttamente con qualsiasi altro formato dovrai progettare e standardizzare un certo formato per i tuoi link. I collegamenti ipertestuali sono standard in XML, ma non in JSON. Esistono standard di bozza per JSON, come HAL .

Infine, REST non è per tutti, e una dimostrazione di ciò è il modo in cui la maggior parte delle persone risolve i loro problemi molto bene con le API HTTP che erroneamente hanno chiamato REST e non si sono mai avventurate oltre. REST è difficile da fare a volte, soprattutto all'inizio, ma paga nel tempo con un'evoluzione più semplice da parte del server e la capacità di adattamento dei clienti alle modifiche. Se hai bisogno di fare qualcosa in modo rapido e semplice, non preoccuparti di ottenere REST correttamente. Probabilmente non è quello che stai cercando. Se hai bisogno di qualcosa che dovrà rimanere online per anni o addirittura decenni, allora REST è per te.


  • SOAP è un protocollo mentre REST è architettura.
  • SOAP espone un comportamento che rappresenta la logica mentre REST espone risorse che rappresentano i dati.
  • In termini di consumo, il servizio REST è molto più semplice di SOAP. Con l'overhead di REST della gestione degli inviluppi XML viene eliminato il che rende più veloce il confronto con SOAP.
  • SOAP ha fornito buone opzioni di sicurezza rispetto a REST.
  • Per l'interazione macchina-macchina e le soluzioni aziendali è preferibile il SOAP, ma per REST dell'API pubblico è l'opzione migliore quasi il 70% delle API pubbliche sono REST.
  • REST è leggero, manutenibile e scalabile.
  • REST è indipendente dal dispositivo, ovvero il client che utilizza API REST può essere qualsiasi dispositivo Mobile, Notebook, TV ecc.
  • Con la nuvola che entra in azione. L'applicazione si sta lentamente spostando su sistemi basati su cloud come Azure, Amazon AWS. Questi sistemi sono costruiti ed espongono le API REST. Quindi è una buona idea creare un'applicazione nella parte superiore dell'API REST.

REST Vs SOAP


REST vs SOAP non è la domanda giusta da chiedere.

REST , a differenza di SOAP non è un protocollo.

REST è uno stile architettonico e un design per architetture software basate su rete.

REST concetti REST sono indicati come risorse. Una rappresentazione di una risorsa deve essere apolidi. È rappresentato tramite un tipo di media. Alcuni esempi di tipi di media includono XML , JSON e RDF . Le risorse sono manipolate dai componenti. I componenti richiedono e manipolano le risorse tramite un'interfaccia uniforme standard. Nel caso di HTTP, questa interfaccia è costituita da operazioni HTTP standard, ad esempio GET , PUT , POST , DELETE .

La domanda di @ Abdulaziz chiarisce il fatto che REST e HTTP sono 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 delle preoccupazioni. Tutte le applicazioni costruite nello stile RESTful devono anche essere client-server in linea di principio.

apolide

Ogni richiesta del client al server richiede che il suo stato sia pienamente rappresentato. Il server deve essere in grado di comprendere completamente la richiesta del client senza utilizzare il contesto del server o lo stato della sessione del server. Ne consegue che tutto lo stato deve essere mantenuto sul client.

cacheable

È possibile utilizzare i vincoli di cache, consentendo in tal modo di contrassegnare i dati di risposta come memorizzabili nella cache o non memorizzabili nella cache. Qualsiasi dato contrassegnato come memorizzabile nella cache può essere riutilizzato come risposta alla stessa richiesta successiva.

Interfaccia uniforme

Tutti i componenti devono interagire attraverso un'unica interfaccia uniforme. Poiché l'interazione di tutti i componenti avviene tramite questa interfaccia, l'interazione con diversi servizi è molto semplice. L'interfaccia è la stessa! Ciò significa anche che le modifiche all'implementazione possono essere apportate separatamente. Tali cambiamenti, non influenzeranno l'interazione dei componenti fondamentali perché 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 è fuori di fortuna poiché REST lo proibisce. Sul lato positivo, tuttavia, REST è ottimizzato per il web, quindi l'incredibile popolarità di REST su HTTP!

I suddetti concetti rappresentano le caratteristiche di definizione 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 REST Design Principles per maggiori dettagli su REST e sui proiettili sopra indicati.

MODIFICA: aggiorna il contenuto in base ai commenti





soap