Menú

Diferència de SOAP Vs REST: comparació de rendiment i seguretat

  • Principal
  • Altres
  • Diferència de SOAP Vs REST: comparació de rendiment i seguretat

soap vs rest difference

Proveu El Nostre Instrument Per Eliminar Problemes

Aquest tutorial explica els serveis SOAP i REST a Parasoft. Aprendràs apàtrides contra estatals, la seguretat de SOAP sobre REST, per què REST és més ràpid que SOAP, etc.:

També hem tractat les sol·licituds de mostra i la resposta de SOAP i REST en format XML i JSON respectivament.

Cap al final d’aquest tutorial, podreu escriure els vostres programes JSON que s’han explicat amb diferents programes d’exemple juntament amb el concepte Jays Path o JSON Evaluator i Document Keys de Parasoft.

=> Consulteu la sèrie completa de SOATest Tutorial aquí .

SOAP vs REST

Aquest tutorial també descriu els diferents verbs que s’utilitzen a Parasoft o SOAtest Automation Tool, juntament amb els exemples de programació i els seus respectius codis de resposta HTTP i usos. Podreu entendre com construir les vostres suites SOAtest d’una manera millor, que es detallarà al nostre proper tutorial.

També podeu provar de respondre a les preguntes que apareixen a la part inferior un cop hàgiu passat aquest tutorial.

Què aprendreu:

Què és el servei SOAP?

SOAP significa Protocol d’accés a objectes simples . Els protocols no són res més que un conjunt de regles que definiu per a una prova. Es tracta d’un protocol “completament estatal”, a diferència de REST que implica l’ús de WSDL (Web Services Description Language) per descriure serveis web.

Totes les sol·licituds i respostes a SOAP es fan en XML (llenguatge de marcatge extensible). SOAP és més segur en comparació amb el seu homòleg. No proporciona cap processament independent per a diferents mètodes i és per això que es denomina protocol 'complet d'estat'.

Per què SOAP és més segur?

Tot i que SOAP i REST admeten SSL (Secure Socket Layer) per a la protecció de dades, mentre realitza la sol·licitud, SOAP admet la seguretat de serveis web (també coneguda com WS-Security o WSS) per a protecció a nivell d’empresa que no existeix als serveis REST. La seguretat dels serveis web (WS-Security, WSS) és una extensió a SOAP per aplicar seguretat als serveis web.

Un cos de sol·licitud de mostra de SOAP

Parasoft TUP true

Disposem d’un XML que s’utilitzarà com a càrrega útil per formar el cos de sol·licitud del SOAP. Qualsevol llenguatge XML consta de la versió que s'hauria de definir a la part superior de l'script. No us heu de preocupar per les etiquetes, ja que tots els fitxers XML us permeten crear-les, a diferència de l’HTML.

Si esteu provant de generar els tokens mitjançant una sol·licitud SOAP, només heu de proporcionar els paràmetres necessaris, com ara l’identificador d’usuari i la contrasenya, juntament amb l’URL que accediu al cos de la sol·licitud o l’XML sota les etiquetes personalitzades.

A continuació es mostra la captura de pantalla del visor de trànsit de Parasoft (un component que us permet veure el resultat).

visor de trànsit de Parasoft

(imatge font )

Funcions destacades de SOAP

A continuació es detallen algunes de les funcions destacades de SOAP:

# 1) Qualsevol sobre SOAP es pot utilitzar en serveis REST, com ara el testimoni generat, però no al revés. Això vol dir que si heu creat un testimoni amb SOAP, aquest testimoni es pot utilitzar a REST (a la secció Gestor de capçaleres HTTP => Autorització). Però no podeu utilitzar sobres REST en una sol·licitud SOAP.

# 2) SOAP és més segur que REST, ja que utilitza WS-Security per a la transmissió juntament amb Secure Socket Layer.

# 3) SOAP només utilitza XML per a sol·licituds i respostes. No utilitza text pla ni cap altre tipus.

# 4) SOAP està completament estat (no apàtrida), ja que pren tota la sol·licitud en conjunt, a diferència de REST, que proporciona un processament independent de diferents mètodes. A SOAP no hi ha processament independent.

Què és el servei REST?

REST significa Representational State Transfer (Transferència d’estats representatius) . REST és una arquitectura 'apàtrida' que implica múltiples mètodes o verbs mentre tracta de sol·licituds i respostes.

Totes les sol·licituds i respostes a REST es fan en XML, JSON (JavaScript Object Notation) o text normal. REST és més ràpid que SOAP a causa de la implicació de JSON (que és lleuger) en la sol·licitud / càrrega útil de REST.

Cada mètode es processa independentment en REST, motiu pel qual s’anomena arquitectura “sense estat”.

Per què REST és més ràpid?

La naturalesa d'apatridia de REST fa que sigui més ràpid que un SOAP. Cada verb es processa de forma independent i fa ús de l'objecte JSON, que és molt més ràpid quan es passa a qualsevol camp concret d'un document que conté més d'un milió de registres.

Abans de començar els mètodes que s’utilitzen a REST, hem de conèixer JSON i el camí JSON, ja que és el format més comú de transmissió de dades a REST.

Què és JSON?

JSON significa JavaScript Object Notation. És un format que s'utilitza habitualment al client REST.

És autodescriptiu i fàcil d’entendre també. Només heu de passar el JSON a la secció de càrrega útil del mètode REST. És un format d’intercanvi de dades lleuger que permet als serveis REST ser molt més ràpids encara que es tracti d’un milió de registres.

Programació amb JSON

A continuació es mostra un programa de mostra amb només un document anomenat 'telèfon'.

programa de mostra

(imatge font )

Aquest és el meu programa JSON de mostra en el qual he d’obtenir el valor del meu tipus de telèfon. En aquest cas, podeu utilitzar dues tècniques per superar aquest camp. Una és per JSON Path i l’altra per clau de document.

# 1) Mentre tracteu el camí JSON, podeu utilitzar dos mètodes:

$.phone(:1).type $('phone')(':1')('type')

Camí JSON: 1

Sintaxi del camí JSON

Resultat de l’avaluació

# 2) Com que Parasoft no permet el camí JSON, podem utilitzar la clau del document que és una mica senzilla quan es travessa. Només cal que passeu la clau del document juntament amb l'URL a la pestanya de recursos com a

phone.type

Només heu de fer clic al botó Afegeix a la captura de pantalla següent i introduir phone.type i ja heu acabat.

feu clic al botó Afegeix

A l'exemple següent, heu de recórrer l'últim element del camp d'ubicació que és una matriu. Per tant, proveu d’escriure-hi un camí JSON.

Camí JSON

com puc executar un fitxer jar

Com podeu veure a les línies 37 i 39 (més amunt), s'han escrit dos camins JSON diferents per al mateix recorregut fins a l'últim element del camp d'ubicació. De la mateixa manera, podeu crear el vostre JSON (un document imbricat complex) i provar d’escriure el camí JSON amb finalitats pràctiques.

RESULTAT:

('Helsingborg')

Podeu provar tants JSON com vulgueu, en un lloc web obert anomenat Avaluador en línia JSON

Mètodes / Verbs a Restful Services

Els serveis REST proporcionen una àmplia gamma de mètodes que també es coneixen com a verbs per a un tipus de sol·licitud diferent. Aquests inclouen principalment POST, PUT, PATCH, OBTENIR, ELIMINAR, PERSONALITZAT .

POST

Aquest mètode és l’encarregat de crear el registre. Quan s’executa amb èxit, el codi de resposta HTTP és 201.

A continuació es mostra la mostra JSON que il·lustra el POST.

{ “Test”: { “Tester Name”: “Saket Saurav”, “Designation”: “QA”, “Test2”: { “Testing”: “Nested Document”, “Platform”: “Windows” } } }

Quan passem aquest JSON com a cos de sol·licitud, es crearà el document amb un codi de resposta 201.

ACONSEGUIR

Aquest és un altre mètode o verb que s’utilitza per recuperar el document o el registre. Quan s’executa amb èxit el GET, el codi de resposta serà 200. No conté cap cos de sol·licitud ni càrrega útil.

Tot el que heu de fer és prémer el mateix URL mitjançant el mètode GET a la pestanya de recursos del Parasoft mitjançant la clau del document com a 'Prova'. Encara que no passeu cap clau de document, obtindrà el document sencer.

Suposem que passem la clau del document com a 'Test.Test2' i, a continuació, obtindrà el registre següent.

{ “Test”: { “Test2”: { “Testing”: “Nested Document”, “Platform”: “Windows” } } }

POSA

Aquest mètode s'utilitza per actualitzar el document i té un codi de resposta de 200 després de l'execució correcta.

Tot i que POST i PUT no difereixen molt i tot depèn del desenvolupador de com volen codificar. Sobretot, els desenvolupadors utilitzen el mètode PUT quan volen actualitzar algun valor de camp.

Per exemple: Si volem canviar algun valor del document JSON anterior inserit per POST, passarem tot el cos de la sol·licitud amb el valor actualitzat mitjançant el mètode PUT.

{ “Test”: { “Tester Name”: “Saket Saurav”, “Designation”: “QA”, “Test2”: { “Testing”: “Nested Document”, “Platform”: “Updated Windows” } } }

Quan veiem la resposta al visor de trànsit, el valor del camp s'actualitzarà com a

'Plataforma': 'Windows actualitzat'

PATCH (PERSONALITZAT)

Aquest és un altre mètode que només s’utilitza per actualitzar el registre. La majoria de desenvolupadors prefereixen aquest mètode sobre el mètode PUT, ja que fa un ús millor dels recursos. Si voleu actualitzar algun valor de camp al vostre document, tot el que heu de fer és passar només aquest camp amb el valor actualitzat del registre.

Diguem, si volem actualitzar el registre POST, només utilitzarem el cos de sol·licitud següent mentre fem servir PATCH.

{“Test”: { “Test2”: { “Testing”: “Nested Document”, “Platform”: “Updated Windows” } } }

Com heu notat, aquí no hem aprovat els valors de camp de 'Prova', a diferència del mètode PUT. L’execució correcta us proporcionarà un codi de resposta de 200 o 201.

ESBORRAR

Com el seu propi nom indica, suprimirà el registre també conegut com a preferències. Això no conté cap cos de sol·licitud com GET i sovint té el codi de resposta com a 203 (Sense contingut). Si hem de suprimir tot el document a la JSON anterior, només passarem la clau del document com a.

Test

Això suprimirà tot el document. Si no passem la clau del document, també esborrarà tot el document.

Trampes de l’entrevistador

P # 1) La majoria dels entrevistadors intenten confondre quan et demanen que han obtingut amb èxit un codi de resposta d'operació de supressió de 200 en lloc de 204. En aquest tipus de situacions, què he de fer? Haig de comunicar-ho com a error?

Resposta: La resposta a la pregunta anterior és senzilla. No cal plantejar cap error. En lloc d’això, podeu parlar amb el desenvolupador o intentar observar l’altra resposta de l’operació de supressió. Un codi de resposta 200 sempre indica l'operació reeixida i 204 és específic per a DELETE. És possible que els desenvolupadors en facin servir 200 per a totes les operacions reeixides.

Q # 2) Com puc comprovar si els valors de camp particulars són correctes o no sense utilitzar una base de dades en una sol·licitud JSON d'1 milió de línies de codi?

Resposta: La resposta és enviant la clau del document a l’operació GET. L'URL de mostra es mostrarà com es mostra a continuació:

https://resource-name.com/context-key/document-key

A l'URL anterior, la vostra clau de context obtindrà aquest JSON concret d'un milió de registres i la clau del document obtindrà el valor de camp concret d'aquest registre.

P # 3) Si no especifiqueu cap nom de document a sobre del meu JSON, què he de passar com a clau de document per obtenir tot el document?

Resposta: Es pot passar qualsevol cosa. Si exactament. Si no teniu cap nom de document especificat i si només hi ha camps i valors presents al document, podeu passar qualsevol valor de cadena. Aquesta cadena es tractarà automàticament com la vostra clau de document.

Resum

A hores d'ara, hauríeu de tenir una bona idea sobre els serveis web SOAP i REST, la seva estructura, les principals diferències entre ells, les seves funcions i ús.

A més, en aquest tutorial hem tractat els mètodes més comuns / importants (també coneguts com a verbs) que s’utilitzen als serveis REST juntament amb la programació JSON i el camí JSON amb finalitats d’avaluació.

PREV Tutorial | NEXT Tutorial

Lectura recomanada

^