web services tutorial
Questo tutorial sui servizi Web spiega l'architettura, i tipi e i componenti di un servizio Web insieme a terminologie importanti e le differenze tra SOAP e REST:
In questo Serie completa di tutorial sul test delle API , abbiamo esplorato tutto Test API nel nostro precedente tutorial. Segui questo tutorial per acquisire familiarità con WSDL e UDDI e come archiviano e definiscono un servizio Web.
Questo tutorial spiegherà anche come funzionano internamente i servizi Web quando un'applicazione client effettua una richiesta. Anche WSS, che è un altro concetto molto importante dei servizi SOAP, è spiegato qui.
Cosa imparerai:
Terminologie importanti nel test dei servizi Web
Prima di iniziare a esplorare i servizi Web, è necessario acquisire familiarità con i termini importanti utilizzati nel test dei servizi Web.
Iniziamo!!
# 1) Interoperabilità
I servizi Web supportano 'Un codice diverse applicazioni'. Ciò significa un codice generico per tutte le applicazioni su piattaforme diverse.
Pertanto, l'interoperabilità è il processo che consente a più applicazioni di comunicare con le altre applicazioni che risiedono su una piattaforma diversa.
# 2) Autenticazione e autorizzazione
Questi vengono utilizzati principalmente nei servizi Web SOAP. In termini generali, Autenticazione significa convalidare qualcosa mentre Autorizzazione significa dare / avere il diritto di accedere a qualcosa.
Per esempio - Se ho una pagina Facebook, posso essere trattato come un utente autenticato di Facebook. Se invece hai il diritto di visualizzare le mie foto su Facebook, sei un utente autorizzato.
Combinando questi due possiamo dire che 'Tutti gli utenti autenticati che hanno accesso alle risorse sono noti come utenti autorizzati per tali risorse'.
La stessa cosa accade nei servizi Web, ovvero l'ID utente e la password utilizzati per generare il token coprono la parte di autenticazione e questo token che verrà utilizzato per inviare una richiesta al server Web copre la parte di autorizzazione.
# 3) Architettura liberamente accoppiata
I servizi Web sono basati su un'architettura Loosely Coupled. Ciò significa che le interfacce dei servizi Web sono di natura dinamica (modifiche durante una data sequenza temporale). Ma la logica del client non deve necessariamente cambiare durante l'interazione con il servizio.
Ciò facilita l'integrazione di più software in modo più efficiente. Se si trattava di un'architettura Tightly Coupled, ogni volta che l'interfaccia cambia, la logica del client deve essere modificata per renderla sincronizzata con il servizio.
# 4) Artefatto
È un termine utilizzato nei servizi Web per denotare informazioni o dati. Non si tratta dell'intero dato ma di un'informazione che può includere un URL o URI, una chiave di contesto, una chiave del documento, un payload o immagini di supporto.
# 5) Punto finale
Questo è un termine molto comune che viene utilizzato in ogni richiesta del servizio web. Questo è l'URL completo che raggiunge l'istanza del servizio Web.
Per esempio - https://www.facebook.com/imsaket -> questo è l'URL completo o l'endpoint che ha facebook.com come URL e 'imsaket' viene passato come chiave di contesto per identificare in modo univoco un indirizzo specifico.
modello di report di riepilogo del test in Excel
# 6) Idempotente
Questo è nell'interazione client-server in cui non importa quante volte colpisci l'istanza del servizio e il server restituirà sempre la stessa risposta al client.
# 7) Marshalling e Demarshalling
Come sappiamo, l'incapsulamento è un principio OOPS definito come il raggruppamento di codice e dati in uno solo. La stessa cosa accade nei servizi Web SOAP. Quando avvolgiamo o incapsuliamo i dati in un payload (XML) per formare un messaggio SOAP e lo inviamo al server, questo processo di incapsulamento viene chiamato Marshalling.
Il Demarshalling è solo il reciproco del Marshalling. Il metodo per decapsulare o scartare dati e codice (XML) dal messaggio SOAP è chiamato 'Demarshalling'.
Cos'è un servizio Web?
Come discusso in precedenza, i servizi Web sono i servizi che servono da una macchina all'altra su una rete.
Esempio di servizi Web: AWS (Amazon Web Services) che consente agli utenti online di visualizzare i prezzi di diversi articoli venduti su Amazon.com e Amazon.in
Componenti dei servizi Web
Di seguito sono elencati i vari componenti dei servizi Web.
# 1) SAPONE
I servizi Web utilizzano il protocollo SOAP (Simple Object Access Protocol) che utilizza XML come payload o corpo della richiesta. Questo è un protocollo stateful poiché non esiste un metodo indipendente per il tipo specifico di operazione.
Tutte le richieste e le risposte vengono eseguite contemporaneamente tramite XML e non vengono forniti esplicitamente metodi indipendenti come GET, PUT, POST o DELETE.
# 2) WSDL
Questa richiesta SOAP utilizza WSDL (Web Services Description Language) che è un componente molto utile del servizio Web.
Questo definisce dove risiede effettivamente il Web Service e anche il tipo di Web Service da prelevare per una specifica richiesta. Ciò utilizza un file XML che descrive la funzionalità del servizio Web.
# 3) UDDI
Un altro componente utile è UDDI . Questo sta per Universal Description Discovery and Integration. C'è un fornitore di servizi che fornisce il servizio Web. Quindi, per un particolare fornitore di servizi, questo UDDI viene utilizzato per descrivere, scoprire e pubblicare tali servizi Web.
UDDI è responsabile di consentire a un client di scoprire (UDDI fornisce un repository per WSDL) dove si trova il file XML di WSDL. Ecco come viene definito e descritto un servizio Web.
# 4) XML-RPC
È l'acronimo di Extensible Markup Language - Remote Procedure. Un altro componente molto importante del servizio Web è XML - RPC che è responsabile dell'invio di messaggi attraverso i sistemi. Le richieste e le risposte sono in formato XML e vengono inviate / ricevute tramite HTTP POST.
La caratteristica migliore di XML-RPC è che un'applicazione client che risiede su una piattaforma diversa può comunicare con un server diverso. C'è qualcosa chiamato JSON-RPC che è stato spiegato nell'ultima parte dell'articolo in quanto non costituisce un componente di un servizio Web.
L'architettura di un servizio Web
L'architettura di un servizio Web può essere rappresentata nel diagramma seguente.
Come già sappiamo, una tipica architettura di Web Services comprende tre entità, ovvero un client, un server Web e un Internet per eseguire l'operazione. L'operazione non è altro che la richiesta e la risposta in un'architettura client-server.
Un client è tipicamente un insieme di tutte le applicazioni o sistemi software che richiedono un servizio Web rendendolo così un consumatore di servizi.
Un server Web è un insieme di tutte le applicazioni o sistemi software che forniscono il servizio Web. Ogni servizio Web richiede una rete per funzionare e questo si traduce nella terza entità chiamata Internet.
Questa è solo una panoramica dell'architettura di un servizio Web.
Il diagramma di funzionamento di un Web Service è definito dai tre componenti mostrati di seguito.
- Richiedente servizio (Trova ())
- Fornitore di servizi (Pubblica ())
- Registro dei servizi o repository (Bind ())
Questo è spiegato (in dettaglio con diagramma) nell'architettura di SOAP Service.
come aprire i file .jar
Tipi di servizi Web
Di seguito vengono spiegati in dettaglio due tipi di servizi Web.
# 1) Servizio SOAP
SOAP Service è l'acronimo di Simple Object Access Protocol. I servizi SOAP sono servizi con stato che utilizzano il linguaggio XML per formare una busta. Una busta SOAP può essere descritta in due parti, ovvero una è un file Intestazione e corpo SOAP , l'altro è il protocollo utilizzato per inviare messaggi SOAP.
Questa intestazione SOAP è costituita da autenticazione e autorizzazione che concede l'accesso. Il body rientra nella sezione payload della richiesta che utilizza WSDL per descrivere il Web Service e il protocollo è principalmente HTTP (HyperText Transmission Protocol).
Sicurezza dei servizi Web
I servizi SOAP hanno un livello SSL (Secure Socket Layer) che è responsabile di evitare qualsiasi perdita di dati durante la trasmissione e quindi fornisce crittografia e decrittografia.
Nel frattempo, i servizi SOAP sono più sicuri in quanto dispone anche di WSS (Web Services Security) che garantisce la non divulgazione durante la comunicazione tra il servizio e l'applicazione.
Come tutti sappiamo, ogni Web Service (a differenza delle Web API), necessita di una rete per svolgere il proprio funzionamento. Pertanto, diventa necessario che i servizi Web forniscano sicurezza quando sono connessi a una rete. Pertanto, i servizi Web hanno tre entità importanti per coprire il fattore di sicurezza durante il trasferimento dei messaggi.
- Autenticazione e autorizzazione (Già spiegato sopra).
- Riservatezza: Ciò dipende interamente dall'SSL che fornisce la crittografia e la decrittografia della busta SOAP.
- Sicurezza della rete: Ciò significa estrarre tutte le risposte SOAP e XML - RPC ottenute dal server. Per esempio, Se prendi uno strumento di servizio Web come POSTMAN o PARASOFT, troverai che sotto il gestore dell'intestazione HTTP, c'è un'opzione per impostare il valore del Content-Type. Il valore può essere impostato su Application / JSON in modo che estrarrà tutto REST (poiché i servizi SOAP non supportano le opzioni del gestore dell'intestazione HTTP). Pertanto, puoi passare il tipo di contenuto: Application / XML in un file carico utile stesso sotto forma di XML. Ciò estrarrebbe anche SOAP e XML-RPC.
Questi tre fattori costituiscono la sicurezza dei servizi Web per far fronte agli attacchi esterni.
L'architettura del servizio SOAP
Ogni servizio SOAP dipende da tre entità che alla fine formano l'architettura del servizio SOAP.
- Fornitore di servizi: Tutti i sistemi software o le applicazioni che fanno parte o forniscono il servizio Web.
- Richiedente del servizio: Tutti i sistemi software o le applicazioni che fanno parte delle richieste del servizio Web dal fornitore di servizi.
- Registro dei servizi: Un registro o un repository in cui tutte le informazioni sul servizio Web sono fornite dal fornitore di servizi. (Già discusso in UDDI)
Spiegazione
Queste tre entità interagiscono tra loro per eseguire un'implementazione del servizio Web di successo. Ciò avviene in tre fasi. La prima fase è il Pubblicare() fase in cui un fornitore di servizi fornisce tutti i dettagli su un servizio Web in un registro di servizio o in un repository.
La seconda fase è Trova() dove una richiesta di servizio principalmente l'applicazione client trova i dettagli sul servizio Web da un repository (ha anche un file XML WSDL). L'ultima fase è Rilegatura() dove l'applicazione client o il richiedente del servizio si sincronizza con il fornitore di servizi per l'implementazione finale del servizio web.
# 2) Servizio RESTful
REST sta per Representational State Transfer che è un file Apolidi Servizio.
Si chiama Stateless poiché il server Web non memorizza alcuna informazione sulla sessione client (durata del tempo fino a quando l'applicazione client è connessa e in esecuzione), il che significa che ogni tipo di richiesta viene trattato ed eseguito facilmente con l'aiuto di metodi integrati REST come GET, POST, CUSTOM (PUT), DELETE, HEAD e così via.
Infatti, questi metodi non sono presenti in SOAP.
Metodo o verbi
Ogni metodo in REST ha il suo significato. Di seguito è riportato il briefing su ciascuno di essi.
- OTTENERE: Questo metodo viene utilizzato per recuperare le informazioni inviate al server utilizzando uno dei metodi come PUT o POST. Questo non ha un corpo di richiesta. L'esecuzione riuscita ti darà 200 oggetti risposta.
- INVIARE: Questo metodo viene utilizzato per creare un documento o un record utilizzando un corpo della richiesta, un URL specificato, una chiave del documento, una chiave di contesto, ecc. Lo stesso può essere recuperato utilizzando il metodo GET. L'esecuzione riuscita ti darà una risposta 201.
- METTERE: Questo è sotto l'opzione PERSONALIZZATO disponibile in POSTMAN o PARASOFT. Questo metodo viene utilizzato per aggiornare qualsiasi documento o record già presente. L'esecuzione riuscita ti darà una risposta 201 o 200.
- ELIMINA: Questo metodo viene utilizzato per eliminare qualsiasi record. L'esecuzione riuscita ti darà una risposta 204 (nessun contenuto).
Nota: I codici di risposta HTTP dipendono da come gli sviluppatori codificano e possono essere manipolati a volte. Abbiamo elencato i codici di risposta comuni che otteniamo da ciascun tipo di metodo.
cos'è tdd e bdd (framework cucumber)
L'architettura del servizio REST
L'architettura del servizio REST dipende da due entità, ovvero Consumatore di servizi o Richiedente e Fornitore di servizi. Il Consumatore di servizi è colui che si avvale del Servizio Web e il Fornitore di servizi è la raccolta di software o sistema che fornisce il Servizio Web.
L'applicazione client, che in genere è un consumatore di servizi, utilizza metodi integrati di REST, un URL o URI, una versione HTTP e un payload (se supportato dal metodo).
SAPONE vs RIPOSO
Sebbene questi due tipi di servizi Web vengano utilizzati per eseguire la richiesta e la risposta, sono completamente diversi nel modo in cui operano.
Le loro differenze sono elencate in basso per riferimento.
- L'inviluppo SOAP può essere utilizzato nel REST ma non viceversa. Per esempio. Un token utente creato in SOAP può essere passato nella richiesta REST sotto il gestore dell'intestazione HTTP -> Autorizzazione.
- SOAP è in genere più sicuro dei servizi REST poiché i servizi SOAP forniscono WSS oltre a SSL. Questo SSL è presente sia in SOAP che in REST.
- SOAP è più lento di REST poiché l'elaborazione della richiesta richiede più tempo in SOAP a causa del formato dati XML. REST utilizza JSON che è molto leggero e quindi lo rende più veloce.
- SOAP non ha alcun metodo integrato ma REST ha GET, PUT, POST, ecc.
- SOAP è con stato mentre REST è senza stato.
- I corpi di richiesta e risposta in SOAP supportano solo il formato dati XML. In REST, i corpi di richiesta e risposta supportano molti formati di dati come JSON, XML, testo normale e così via.
Conclusione
Questa esercitazione sui servizi Web ha illustrato l'architettura, i componenti e i tipi di servizi Web.
Abbiamo anche appreso le differenze tra i servizi SOAP e REST, insieme ad altri concetti e terminologie importanti relativi ai servizi Web.
Speriamo che questo tutorial ti abbia aiutato a comprendere i servizi Web !!
Tutorial PREV | PROSSIMO Tutorial
Lettura consigliata
- Tutorial Python DateTime con esempi
- Tutorial Java SWING: contenitore, componenti e gestione degli eventi
- Tutorial sull'iniezione di HTML: tipi e prevenzione con esempi
- Tutorial sullo scripting della shell di Unix con esempi
- Selenio Trova elemento per tutorial di testo con esempi
- Tutorial sulle funzioni principali di Python con esempi pratici
- Tutorial sul test pairwise o sul test per tutte le coppie con strumenti ed esempi
- Esercitazione sul test di configurazione con esempi