API SOAP e REST: differenza tra servizi Web

Differenza tra SAPONE e RIPOSO

Ogni tecnica ha i suoi vantaggi e svantaggi. Quindi, è sempre bene capire in quali situazioni ogni disegno dovrebbe essere utilizzato. Questo tutorial sulle differenze tra API REST e SOAP approfondirà alcune delle differenze chiave tra API REST e SOAP e le sfide che potresti incontrare durante il loro utilizzo.
Di seguito è riportata la differenza principale tra SOAP e API REST

<?xml version="1.0"?>
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV
="http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle
=" http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
 <Demo.guru99WebService
 xmlns="http://tempuri.org/">
   <EmployeeID>int</EmployeeID>
   </Demo.guru99WebService>
 </soap:Body>
</SOAP-ENV:Envelope>

{"city":"Mumbai","state":"Maharastra"}

Quando usare REST?

Uno degli argomenti più controversi è quando utilizzare REST o quando utilizzare SOAP durante la progettazione di servizi Web. Di seguito sono riportati alcuni dei fattori chiave che determinano quando utilizzare la tecnologia API REST e SOAP per i servizi Web I servizi REST devono essere utilizzati nei seguenti casi

• Risorse e larghezza di banda limitate – Poiché i messaggi SOAP hanno contenuti più pesanti e consumano una larghezza di banda molto maggiore, REST dovrebbe essere utilizzato nei casi in cui la larghezza di banda della rete rappresenta un limite.
• Apolidia – Se non è necessario mantenere uno stato di informazioni da una richiesta all'altra, è necessario utilizzare REST. Se è necessario un flusso di informazioni adeguato in cui alcune informazioni da una richiesta devono confluire in un'altra, SOAP è più adatto a tale scopo. Possiamo prendere l'esempio di qualsiasi sito di acquisto online. Questi siti normalmente richiedono che l'utente aggiunga prima gli articoli che devono essere acquistati al carrello. Tutti gli articoli del carrello vengono quindi trasferiti alla pagina di pagamento per completare l'acquisto. Questo è un esempio di un'applicazione che necessita della funzionalità di stato. Lo stato degli articoli nel carrello deve essere trasferito alla pagina di pagamento per un'ulteriore elaborazione.
• Caching – Se è necessario memorizzare nella cache molte richieste, REST è la soluzione perfetta. A volte, i client potrebbero richiedere la stessa risorsa più volte. Ciò può aumentare il numero di richieste inviate al server. Implementando una cache, i risultati delle query più frequenti possono essere archiviati in una posizione intermedia. Pertanto, ogni volta che il client richiede una risorsa, controllerà prima la cache. Se le risorse esistono, non procederà al server. Pertanto la memorizzazione nella cache può aiutare a ridurre al minimo la quantità di viaggi effettuati sul server web.
• Facilità di codifica – La codifica dei servizi REST e la successiva implementazione è molto più semplice di SOAP. Pertanto, se è necessaria una soluzione rapida per i servizi Web, REST è la strada da percorrere.

Successivamente in questo tutorial sulle differenze SOAP e REST, impareremo quando utilizzare l'API SOAP.

Quando usare il SAPONE?

SOAP dovrebbe essere utilizzato nei seguenti casi

1. Elaborazione asincrona e successiva invocazione – Se è necessario che il cliente abbia bisogno di un livello garantito di affidabilità e sicurezza, il nuovo standard SOAP di SOAP 1.2 fornisce molte funzionalità aggiuntive, soprattutto quando si tratta di sicurezza.
2. Un mezzo di comunicazione formale – se sia il client che il server hanno un accordo sul formato di scambio allora SOAP 1.2 fornisce delle specifiche rigide per questo tipo di interazione. Un esempio è un sito di acquisti online in cui gli utenti aggiungono articoli al carrello prima che venga effettuato il pagamento. Supponiamo di avere un servizio web che effettua il pagamento finale. Può esserci un accordo definitivo secondo cui il servizio web accetterà solo il nome dell'articolo nel carrello, il prezzo unitario e la quantità. Se esiste uno scenario del genere, è sempre meglio utilizzare il protocollo SOAP.
3. Operazioni con stato – se l'applicazione prevede il mantenimento dello stato da una richiesta all'altra, lo standard SOAP 1.2 fornisce la struttura WS* per supportare tali requisiti.

Successivamente, in questa differenza tra API REST e SOAP, impareremo le sfide con l'API SOAP.

Sfide nell'API SOAP

L'API è conosciuta come Application Programming Interface ed è offerto sia dal client che dal server. Nel mondo client, questo è offerto dal browser mentre nel mondo server è ciò che viene fornito dal servizio web che può essere SOAP o REST.

Sfide con l'API SOAP

1. File WSDL: una delle sfide principali dell'API SOAP è il documento WSDL stesso. Il documento WSDL è ciò che comunica al client tutte le operazioni che possono essere eseguite dal servizio web. Il documento WSDL conterrà tutte le informazioni come i tipi di dati utilizzati nei messaggi SOAP e tutte le operazioni disponibili tramite il servizio web. Il frammento di codice seguente è solo parte di un file WSDL di esempio.

<?xml version="1.0"?>
<definitions name="Tutorial"             
	targetNamespace=http://demo.guru99.com/Tutorial.wsdl             
	xmlns:tns=http://demo.guru99.com/Tutorial.wsdl             
	xmlns:xsd1=http://demo.guru99.com/Tutorial.xsd            
	xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/
	xmlns="http://schemas.xmlsoap.org/wsdl/"> 

	<types>  
		<schema targetNamespace=http://Demo.guru99.com/Tutorial.xsd
		xmlns="http://www.w3.org/2000/10/XMLSchema">

      	<element name="TutorialNameRequest">    
			<complexType>          
				<all>           
					<element name="TutorialName" type="string"/>         
				</all>       
			</complexType>    
		</element>     
	<element name="TutorialIDRequest">        
		<complexType>          
			<all>           
				<element name="TutorialID" type="number"/>         
			</all>       
		</complexType>      
	</element>   
	</schema>  
</types>	

Come nel file WSDL sopra, abbiamo un elemento chiamato "TutorialName" che è del tipo String che fa parte dell'elemento TutorialNameRequest.

Supponiamo ora che il file WSDL dovesse cambiare in base ai requisiti aziendali e che TutorialName dovesse diventare TutorialDescriptione. Ciò significherebbe che tutti i client attualmente connessi a questo servizio Web dovrebbero quindi apportare la modifica corrispondente nel proprio codice per accogliere la modifica nel file WSDL.

Ciò mostra la sfida più grande del file WSDL, ovvero lo stretto contratto tra il client e il server e che una modifica potrebbe causare un grande impatto, nel complesso, sulle applicazioni client.

2. Dimensione del documento: l'altra sfida chiave è la dimensione dei messaggi SOAP che vengono trasferiti dal client al server. A causa dei messaggi di grandi dimensioni, l'utilizzo di SOAP in luoghi in cui la larghezza di banda rappresenta un limite può rappresentare un grosso problema.

Successivamente, in questa differenza tra RESTful e SOAP, impareremo le sfide con l'API REST.

Sfide nell'API REST

1. Mancanza di sicurezza – REST non impone alcun tipo di sicurezza come SOAP. Questo è il motivo per cui REST è molto appropriato per gli URL disponibili al pubblico, ma quando si tratta di dati riservati trasmessi tra il client e il server, REST è il meccanismo peggiore da utilizzare per i servizi Web.
2. Mancanza di Stato – La maggior parte delle applicazioni web richiedono un meccanismo con stato. Ad esempio, se disponi di un sito di acquisto dotato del meccanismo di carrello degli acquisti, è necessario conoscere il numero di articoli nel carrello prima che venga effettuato l'acquisto effettivo. Sfortunatamente, l'onere di mantenere questo stato spetta al client, il che rende l'applicazione client più pesante e difficile da gestire.

Differenza tra SOAP Vs CORBA Vs DCOM Vs Java RMI

Tecniche di accesso remoto come RPC (Chiamate di procedure remote) erano di uso comune prima che arrivassero SOAP e REST API. Le varie tecniche di accesso remoto disponibili sono menzionate di seguito.

1. CORBA – Questo era noto come CCOMUNE Ooggetto Rrichiesta Brocker Architecture. Questo sistema è stato messo in atto per garantire che le applicazioni sviluppate su diverse piattaforme potessero comunicare tra loro. CORBA era basato su un'architettura orientata agli oggetti, ma non era necessario che l'applicazione chiamante fosse basata su questa architettura. Lo svantaggio principale di questa tecnica era che doveva essere sviluppata in un linguaggio separato chiamato Interface Definition Language, e presentava semplicemente un linguaggio aggiuntivo che doveva essere appreso dagli sviluppatori per utilizzare il sistema CORBA.
2. DCOM - Questo è il Ddistribuito Component Ooggetto Model, che è un proprietario Microsoft tecnologia per consentire ai client di accedere a componenti remoti. Il problema più grande con questo meccanismo era che spettava all'applicazione client liberare le risorse quando non erano più necessarie. In secondo luogo, quando il client inviava la richiesta, spettava al client assicurarsi che la richiesta fosse inserita o sottoposta a marshalling in modo corretto. modo affinché il servizio web possa comprendere la richiesta inviata. Un altro problema era se l'applicazione client fosse un file Java applicazione basata su DCOM (Microsoft Technology) era necessaria una codifica aggiuntiva per garantire che le applicazioni realizzate in altri linguaggi di programmazione potessero funzionare con i servizi Web basati su DCOM.
3. Java RMI - Conosciuto come Java Remote Metodo Invocazione, questa era Java implementazione su come gli oggetti remoti potrebbero essere chiamati tramite chiamate di procedure remote. La più grande limitazione di questa tecnologia era quella Java RMI può essere eseguito solo su a Java Macchina virtuale. Ciò significava che anche l'applicazione chiamante doveva essere eseguita su Java quadro da utilizzare Java RMI.

Le principali differenze tra SOAP e queste tecniche sono le seguenti

1. Lavorare su HTTP – Tutte le tecniche RPC hanno un grosso limite: non funzionano con il protocollo HTTP. Poiché tutte le applicazioni sul Web dovevano funzionare su questo protocollo, questo rappresentava un grosso ostacolo per i client che dovevano accedere a questi servizi Web in stile RPC.
2. Lavorare con porte non standard – Poiché i servizi Web in stile RPC non funzionavano tramite il protocollo HTTP, dovevano essere aperte porte separate affinché i client potessero accedere alle funzionalità di questi servizi Web.