web services tutorial
Denne vejledning til webservices forklarer arkitekturen, typerne og komponenterne i en webservice sammen med vigtige terminologier og forskellene mellem SOAP Vs REST:
I denne Komplet API-testvejledningsserie , vi udforskede alt om API-test i vores tidligere tutorial. Gå gennem denne vejledning for at blive fortrolig med WSDL og UDDI, og hvordan de gemmer og definerer en webservice.
Denne tutorial forklarer også, hvordan Web Services fungerer internt, når en klientapplikation fremsætter en anmodning. WSS, som er et andet meget vigtigt koncept for SOAP Services, forklares også her.
Hvad du vil lære:
Vigtige terminologier i test af webservices
Før vi begynder at udforske webservices, skal vi være fortrolige med de vigtige udtryk, der bruges i test af webservices.
Lad os begynde!!
# 1) Interoperabilitet
Webtjenester understøtter “One Code Different Applications”. Dette betyder en generisk kode til alle applikationer på tværs af forskellige platforme.
Interoperabilitet er således den proces, der letter flere applikationer til at kommunikere med de andre applikationer, der findes på en anden platform.
# 2) Godkendelse og godkendelse
Disse bruges hovedsageligt i SOAP Web Services. Generelt betyder godkendelse validering af noget, mens autorisation betyder at give / have ret til adgang til noget.
For eksempel - Hvis jeg har en Facebook-side, kan jeg behandles som en godkendt bruger af Facebook. Mens du har ret til at se mine fotos på facebook, er du en autoriseret bruger.
Ved at kombinere disse to kan vi sige, at 'Alle godkendte brugere, der har adgang til ressourcerne, er kendt som autoriserede brugere for disse ressourcer.'
Den samme ting sker i Web Services, dvs. bruger-id'et og adgangskoden, der bruges til at generere tokenet, dækker autentificeringsdelen, og dette token, som vil blive brugt til at sende en anmodning til webserveren, dækker autorisationsdelen.
# 3) Løst koblet arkitektur
Webtjenester er baseret på løst koblet arkitektur. Dette betyder, at grænsefladerne til Web Services er dynamiske (ændringer under en given tidslinje). Men klientlogikken behøver ikke nødvendigvis at ændre sig, mens den interagerer med tjenesten.
Dette letter integrationen af flere software på en mere effektiv måde. Hvis det var en tæt koblet arkitektur, skal klientlogikken ændres hver gang når grænsefladen ændres, for at den kan synkroniseres med tjenesten.
# 4) Artefakt
Det er et udtryk, der bruges i Web Services til at betegne information eller data. Dette er ikke hele dataene, men et stykke information, der kan omfatte en URL eller URI, kontekstnøgle, dokumentnøgle, en nyttelast eller understøttende billeder.
# 5) Slutpunkt
Dette er et meget almindeligt udtryk, der bruges i enhver anmodning fra webservicen. Dette er den komplette URL, der rammer forekomsten af webservicen.
For eksempel - https://www.facebook.com/imsaket -> dette er den komplette URL eller slutpunkt, som har facebook.com som URL, og 'imsaket' sendes som en kontekstnøgle for entydigt at identificere en bestemt adresse.
bedste salgssystem til iPad
# 6) Idempotent
Dette er i klient-server-interaktionen, hvor det ikke betyder noget, hvor mange gange du rammer forekomsten af tjenesten, og serveren returnerer altid det samme svar til klienten.
# 7) Marshalling og Demarshalling
Som vi ved, er indkapsling et OOPS-princip, der defineres som indpakning af kode og data til en. Den samme ting sker i SOAP Web Services. Når vi indpakker eller indkapsler data i nyttelast (XML) for at danne en SOAP-besked og sender dem til serveren, kaldes denne indkapslingsproces Marshalling.
Demarshalling er bare det gensidige ved Marshalling. Metoden til at afkapsle eller pakke data og kode (XML) fra SOAP-meddelelsen kaldes “Demarshalling”.
Hvad er en webservice?
Som diskuteret tidligere er Web Services de tjenester, der tjener fra en maskine til en anden over et netværk.
Eksempel på webservices: AWS (Amazon Web Services), der giver onlinebrugere mulighed for at se priserne på forskellige varer, der sælges på Amazon.com og Amazon.in
Komponenter af webservices
Nedenfor er de forskellige komponenter i Web Services.
# 1) SÆBE
Webtjenester bruger Simple Object Access Protocol (SOAP), der bruger XML som en nyttelast eller anmodningsinstans. Dette er en stateful protokol da der ikke er nogen uafhængig metode til den specifikke type operation.
Alle anmodninger og svar overføres på én gang gennem XML, og ingen uafhængige metoder som GET, PUT, POST eller SLET leveres eksplicit.
# 2) WSDL
Denne SOAP-anmodning gør brug af Web Services Description Language (WSDL) hvilket er en meget nyttig komponent i Web Service.
Dette definerer, hvor webservicen faktisk ligger, og hvilken type webservice der skal afhentes til en specifik anmodning. Dette gør brug af en XML-fil, der beskriver webservicefunktionaliteten.
# 3) UDDI
En anden nyttig komponent er UDDI . Dette står for Universal Description Discovery and Integration. Der er en tjenesteudbyder, der leverer webservicen. Derfor, for en bestemt tjenesteudbyder, bruges denne UDDI til at beskrive, opdage og udgive disse webtjenester.
UDDI er ansvarlig for at lade en klient finde ud af (UDDI leverer et lager til WSDL), hvor WSDLs XML-fil er placeret. Sådan defineres og beskrives en webservice.
# 4) XML-RPC
Det står for Extensible Markup Language - Remote Procedure. En anden meget vigtig komponent i Web Service er XML - RPC, som er ansvarlig for at sende meddelelser på tværs af systemer. Anmodninger og svar er i form af XML og sendes / modtages via HTTP POST.
Det bedste ved XML-RPC er, at en klientapplikation, der er bosat på en anden platform, kan kommunikere med en anden server. Der er noget, der hedder JSON-RPC, som er blevet forklaret i sidste del af artiklen, da det ikke udgør en komponent i en webservice.
Arkitekturen til en webservice
Arkitekturen for en webservice kan afbildes i følgende diagram.
Som vi allerede ved, omfatter en typisk Web Services-arkitektur tre enheder, dvs. en klient, en webserver og et internet til at udføre operationen. Operationen er intet andet end anmodningen og svaret i en klientserverarkitektur.
En klient er typisk et sæt af alle applikationer eller softwaresystemer, der anmoder om en webservice og derved gør det til en serviceforbruger.
En webserver er et sæt af alle applikationer eller softwaresystemer, der leverer webservice. Hver webservice kræver et netværk for at udføre, og dette resulterer i den tredje enhed kaldet Internettet.
Dette er kun en oversigt over arkitekturen i en webservice.
Arbejdsdiagrammet for en webservice er defineret af de tre komponenter vist nedenfor.
- Tjenesteanmoder (Find ())
- Tjenesteudbyder (Publicer ())
- Tjenesteegister eller lager (Bind ())
Dette forklares (detaljeret med diagram) i SOAP Service-arkitekturen.
hvordan man åbner shockwave flash-objekt
Typer af webtjenester
To typer webtjenester forklares detaljeret nedenfor.
# 1) SOAP-service
SOAP Service står for Simple Object Access Protocol. SOAP-tjenester er statefulde tjenester, der bruger XML-sprog til at danne en konvolut. En SOAP-konvolut kan beskrives i to portioner, dvs. den ene er en SOAP header og krop , den anden er protokol bruges til at sende SOAP-meddelelser.
Denne SOAP-header består af godkendelse og autorisation, som giver adgang. Kroppen kommer under nyttelasteafsnittet i anmodningen, som bruger WSDL til at beskrive webservicen, og protokollen er hovedsageligt HTTP (HyperText Transmission Protocol).
Web Services sikkerhed
SOAP-tjenester har et SSL-lag (Secure Socket Layer), som er ansvarlig for at undgå enhver datalækage under transmission og dermed giver kryptering og dekryptering.
I mellemtiden er SOAP-tjenesterne mere sikre, da de også har WSS (Web Services Security), som garanterer ingen afsløring under kommunikation mellem tjenesten og applikationen.
Som vi alle ved, har enhver webservice (i modsætning til Web API) brug for et netværk for at udføre dens drift. Således bliver det nødvendigt for Web Services at give sikkerhed, når de er forbundet til et netværk. Derfor har Web Services tre vigtige enheder, der dækker sikkerhedsfaktoren under meddelelsesoverførslen.
- Godkendelse og godkendelse (Forklaret allerede ovenfor).
- Fortrolighed: Dette er helt afhængigt af SSL, som giver kryptering og dekryptering af SOAP-konvolutten.
- Netværkssikkerhed: Dette betyder at udtrække alle de SOAP- og XML - RPC-svar, du får fra serveren. For eksempel, Hvis du tager et Web Service-værktøj som POSTMAN eller PARASOFT, vil du opdage, at der under HTTP-headermanageren er en mulighed for at indstille værdien af indholdstypen. Værdien kan indstilles til applikationen / JSON, så den ekstraherer alle REST (Da SOAP-tjenester ikke understøtter HTTP-headermanagerindstillinger). Således kan du videregive indholdstypen: Application / XML i en nyttelast sig selv i form af XML. Dette ville også udtrække SOAP og XML-RPC.
Disse tre faktorer udgør webservicesikkerhed for at klare de eksterne angreb.
Arkitekturen af SOAP Service
Hver SOAP-tjeneste afhænger af tre enheder, der i sidste ende udgør arkitekturen for SOAP Service.
- Service udbyder: Alle softwaresystemer eller applikationer, der er en del eller leverer webservice.
- Serviceanmoder: Alle softwaresystemer eller applikationer, der er en del af anmodninger om webtjeneste fra tjenesteudbyderen.
- Tjeneste Register: Et register eller lager, hvor alle oplysninger om webservice leveres af tjenesteudbyderen. (Allerede diskuteret i UDDI)
Forklaring
Disse tre enheder interagerer med hinanden for at gennemføre en vellykket implementering af webservicen. Dette gøres i tre faser. Den første fase er Offentliggøre() fase, hvor en tjenesteudbyder fremfører alle detaljerne om en webservice i et serviceregister eller lager.
Den anden fase er Finde() hvor en serviceanmodning hovedsageligt finder klientapplikationen detaljerne om webservice fra et lager (har også WSDL XML-fil). Den sidste fase er Bindende () hvor klientapplikationen eller serviceanmoderen synkroniseres med tjenesteudbyderen til den endelige implementering af webservicen.
# 2) RESTful service
REST står for repræsentativ statsoverførsel, som er en Statsløs Service.
j2ee interview spørgsmål og svar til erfarne
Det kaldes Stateless, da webserveren ikke gemmer nogen information om klientsessionen (tidsvarighed, indtil klientapplikationen er tilsluttet og i udførelse), hvilket betyder, at hver anmodningstype behandles og udføres let ved hjælp af REST-indbyggede metoder som GET, POST, CUSTOM (PUT), SLET, HEAD og så videre.
Faktisk er disse metoder ikke til stede i SOAP.
Metode eller verb
Hver metode i REST har sin betydning. Nedenfor er briefingen om hver af dem.
- FÅ: Denne metode bruges til at hente de oplysninger, der sendes til serveren ved hjælp af en af metoderne som PUT eller POST. Dette har ikke et anmodningsorgan. Vellykket udførelse giver dig 200 svarobjekter.
- STOLPE: Denne metode bruges til at oprette et dokument eller en registrering ved hjælp af en anmodningstekst, angivet URL, dokumentnøgle, kontekstnøgle osv. Det samme kan hentes ved hjælp af GET-metoden. En vellykket udførelse giver dig et 201-svar.
- SÆTTE: Dette er under CUSTOM-indstillingen, der er tilgængelig i POSTMAN eller PARASOFT. Denne metode bruges til at opdatere ethvert dokument eller post, der allerede er til stede. Vellykket udførelse giver dig et svar på 201 eller 200.
- SLET: Denne metode bruges til at slette enhver post. Vellykket udførelse giver dig et svar på 204 (intet indhold).
Bemærk: HTTP-svarkoderne afhænger af, hvordan udviklere til tider koder og kan manipuleres. Vi har listet de almindelige svarkoder, som vi får fra hver metodetype.
Arkitekturen af REST Service
Arkitekturen for REST-tjenesten afhænger af to enheder, dvs. serviceforbruger eller rekvirent og serviceudbyder. Serviceforbrugeren er den, der benytter webservicen og tjenesteudbyderen, er indsamlingen af software eller system, der leverer webservicen.
Klientapplikationen, der typisk er en serviceforbruger, bruger indbyggede metoder til REST, en URL eller URI, en HTTP-version og en nyttelast (hvis den understøttes af metoden).
SÅPE vs REST
Selvom disse to typer webtjenester bruges til at udføre anmodningen og svaret, er de helt forskellige i den måde, de fungerer på.
Deres forskelle er anført til din reference.
- SOAP-kuvert kan bruges i REST men ikke omvendt. For eksempel. Et brugertoken, der oprettes i SOAP, kan sendes i REST-anmodningen under HTTP-headermanager -> Autorisation.
- SOAP er typisk mere sikker end REST-tjenester, da SOAP-tjenester leverer WSS bortset fra SSL. Denne SSL findes både i SOAP og REST.
- SOAP er langsommere end REST, da anmodningen behandler mere tid i SOAP på grund af XML-dataformatet. REST bruger JSON, som er meget letvægtet og dermed gør det hurtigere.
- SOAP har ingen indbygget metode, men REST har GET, PUT, POST osv.
- SOAP er stateful, mens REST er statsløs.
- Anmodnings- og svarorganerne i SOAP understøtter kun XML-dataformatet. I REST understøtter anmodnings- og svarorganerne mange dataformater som JSON, XML, almindelig tekst osv.
Konklusion
Denne tutorial i Web Services forklarede arkitekturen, komponenterne og typerne af Web Services.
Vi lærte også om forskelle mellem SOAP- og REST-tjenester sammen med andre vigtige begreber og terminologier relateret til webservices.
Vi håber, at denne tutorial hjalp dig med at forstå webservices !!
PREV-vejledning | NÆSTE vejledning
Anbefalet læsning
- Python DateTime-tutorial med eksempler
- Java SWING Tutorial: Container, komponenter og håndtering af begivenheder
- HTML-injektionsvejledning: Typer og forebyggelse med eksempler
- Unix Shell Scripting Tutorial med eksempler
- Selen Find Element by Text Tutorial med eksempler
- Pythons hovedfunktionsvejledning med praktiske eksempler
- Parvis test eller vejledning til test af alle par med værktøjer og eksempler
- Konfigurationstestvejledning med eksempler