web services tutorial
Denne opplæringen om webtjenester forklarer arkitekturen, typene og komponentene til en webtjeneste sammen med viktige terminologier og forskjellene mellom SOAP Vs REST:
I dette Komplett API Testing Tutorial Series , vi utforsket alt om API-testing i vår forrige opplæring. Gå gjennom denne veiledningen for å bli kjent med WSDL og UDDI og hvordan de lagrer og definerer en webtjeneste.
Denne opplæringen vil også forklare hvordan Web Services fungerer internt når en klientapplikasjon gjør en forespørsel. WSS, som er et annet veldig viktig konsept med SOAP Services, blir også forklart her.
Hva du vil lære:
Viktige terminologier i nettjenestetesting
Før vi begynner å utforske Web Services, bør vi være kjent med de viktige begrepene som brukes i Web Services Testing.
La oss begynne!!
# 1) Interoperabilitet
Webtjenester støtter “One Code Different Applications”. Dette betyr en generisk kode for alle applikasjoner på tvers av forskjellige plattformer.
Dermed er interoperabilitet prosessen som gjør det mulig for flere applikasjoner å kommunisere med de andre applikasjonene som ligger på en annen plattform.
# 2) Autentisering og autorisasjon
Disse brukes hovedsakelig i SOAP Web Services. Generelt sett betyr autentisering validering av noe, mens autorisasjon betyr å gi / ha rett til tilgang til noe.
For eksempel - Hvis jeg har en Facebook-side, kan jeg bli behandlet som en godkjent bruker av Facebook. Mens du har rett til å se bildene mine på facebook, er du en autorisert bruker.
Ved å kombinere disse to kan vi si at 'Alle autentiserte brukere som har tilgang til ressursene er kjent som autoriserte brukere for disse ressursene.'
Det samme skjer i Web Services, dvs. bruker-ID og passord som brukes til å generere token, dekker autentiseringsdelen, og dette token som vil bli brukt til å sende en forespørsel til webserveren dekker autorisasjonsdelen.
# 3) Løst koblet arkitektur
Webtjenester er basert på løs koblet arkitektur. Dette betyr at grensesnittene til webtjenester er dynamiske (endringer i løpet av en gitt tidslinje). Men klientlogikken trenger ikke nødvendigvis å endres mens den kommuniserer med tjenesten.
Dette letter integrasjonen av flere programmer på en mer effektiv måte. Hvis det var en tett koblet arkitektur, må klientlogikken endres hver gang når grensesnittet endres, for å gjøre det synkronisert med tjenesten.
# 4) Artefakt
Det er et begrep som brukes i Web Services for å betegne informasjon eller data. Dette er ikke hele dataene, men et stykke informasjon som kan omfatte en URL eller URI, kontekstnøkkel, dokumentnøkkel, en nyttelast eller støttende bilder.
# 5) Endepunkt
Dette er et veldig vanlig begrep som brukes i alle forespørsler fra nettjenesten. Dette er den komplette URL-en som treffer forekomsten av webtjenesten.
For eksempel - https://www.facebook.com/imsaket -> dette er den komplette URL-en eller endepunktet som har facebook.com som URL og 'imsaket' sendes som kontekstnøkkel for å identifisere en spesifikk adresse unikt.
hvordan du åpner SWF-filer på Windows
# 6) Idempotent
Dette er i klient-server-interaksjonen der det ikke betyr noe hvor mange ganger du treffer forekomsten av tjenesten, og serveren vil alltid returnere det samme svaret til klienten.
# 7) Marshalling and Demarshalling
Som vi vet er innkapsling et OOPS-prinsipp som er definert som innpakning av kode og data til en. Det samme skjer i SOAP Web Services. Når vi pakker inn eller kapsler inn data i nyttelast (XML) for å danne en SOAP-melding og sender den til serveren, kalles denne prosessen med innkapsling Marshalling.
Demarshalling er bare gjensidig av Marshalling. Metoden for å avkapsle eller pakke ut data og kode (XML) fra SOAP-meldingen kalles “Demarshalling”.
Hva er en nettjeneste?
Som diskutert tidligere er Web Services de tjenestene som tjener fra en maskin til en annen over et nettverk.
Eksempel på webtjenester: AWS (Amazon Web Services) som lar brukerne på nettet se prisene på forskjellige varer som selges på Amazon.com og Amazon.in
Komponenter av webtjenester
Nedenfor er de forskjellige komponentene i Web Services.
# 1) SÅPE
Webtjenester bruker Simple Object Access Protocol (SOAP) som bruker XML som nyttelast eller forespørsel. Dette er en stateful protokoll da det ikke er noen uavhengig metode for den spesifikke typen operasjoner.
Alle forespørsler og svar blir transportert samtidig gjennom XML, og ingen uavhengige metoder som GET, PUT, POST eller SLETT er eksplisitt gitt.
# 2) WSDL
Denne SOAP-forespørselen bruker Web Services Description Language (WSDL) som er en veldig nyttig komponent i Web Service.
Dette definerer hvor nettjenesten faktisk bor og hvilken type nettjeneste som skal hentes for en spesifikk forespørsel. Dette bruker en XML-fil som beskriver funksjonen til Web Service.
# 3) UDDI
En annen nyttig komponent er UDDI . Dette står for Universal Description Discovery and Integration. Det er en tjenesteleverandør som tilbyr nettjenesten. Derfor, for en bestemt tjenesteleverandør, brukes denne UDDI til å beskrive, oppdage og publisere disse webtjenestene.
UDDI er ansvarlig for å la en klient finne ut (UDDI tilbyr et depot for WSDL) hvor WSDLs XML-fil ligger. Slik defineres og beskrives en nettjeneste.
# 4) XML-RPC
Det står for Extensible Markup Language - Remote Procedure. En annen veldig viktig komponent i Web Service er XML - RPC som er ansvarlig for sending av meldinger på tvers av systemer. Forespørsler og svar er i form av XML og sendes / mottas gjennom HTTP POST.
Det beste ved XML-RPC er at et klientprogram som bor på en annen plattform kan kommunisere med en annen server. Det er noe som heter JSON-RPC som er forklart i siste del av artikkelen, da det ikke utgjør en komponent i en webtjeneste.
Arkitekturen til en nettjeneste
Arkitekturen til en webtjeneste kan vises i følgende diagram.
Som vi allerede vet, består en typisk Web Services-arkitektur av tre enheter, det vil si en klient, en webserver og et internett for å utføre operasjonen. Operasjonen er ikke annet enn forespørsel og svar i en klient-server-arkitektur.
En klient er vanligvis et sett med alle applikasjoner eller programvaresystemer som ber om en webtjeneste og derved gjør den til en tjenesteforbruker.
En webserver er et sett med alle applikasjoner eller programvaresystemer som tilbyr Web Service. Hver webtjeneste krever at et nettverk skal utføres, og dette resulterer i den tredje enheten som kalles Internett.
Dette er bare en oversikt over arkitekturen til en webtjeneste.
Arbeidsdiagrammet til en webtjeneste er definert av de tre komponentene vist nedenfor.
- Tjenesteforespørseler (Finn ())
- Tjenesteyter (publiser ())
- Tjeneregister eller lager (Bind ())
Dette er forklart (detaljert med diagram) i arkitekturen til SOAP Service.
hvordan åpne shockwave flash-objekt
Typer webtjenester
To typer webtjenester er forklart i detalj nedenfor.
# 1) SOAP-tjeneste
SOAP Service står for Simple Object Access Protocol. SOAP-tjenester er stateful-tjenester som bruker XML-språk for å danne en konvolutt. En SOAP-konvolutt kan beskrives i to porsjoner, dvs. en er en SÅPE overskrift og kropp , den andre er protokoll brukes til å sende SOAP-meldinger.
Denne SOAP-overskriften består av autentisering og autorisasjon som gir tilgang. Kroppen kommer under nyttelastdelen av forespørselen som bruker WSDL til å beskrive webtjenesten, og protokollen er hovedsakelig HTTP (HyperText Transmission Protocol).
Sikkerhet for webtjenester
SOAP-tjenester har et SSL-lag (Secure Socket Layer) som er ansvarlig for å unngå datalekkasje under overføring, og dermed gir kryptering og dekryptering.
I mellomtiden er SOAP-tjenestene sikrere ettersom det også har WSS (Web Services Security) som garanterer ingen avsløring under kommunikasjon mellom tjenesten og applikasjonen.
Som vi alle vet, trenger hver Web Service (i motsetning til Web API) et nettverk for å utføre driften. Dermed blir det nødvendig for Web Services å gi sikkerhet når de er koblet til et nettverk. Derfor har Web Services tre viktige enheter for å dekke sikkerhetsfaktoren under meldingsoverføring.
stable datastruktur c ++
- Autentisering og autorisasjon (Allerede forklart ovenfor).
- Konfidensialitet: Dette er helt avhengig av SSL som gir kryptering og dekryptering av SOAP-konvolutten.
- Nettverksikkerhet: Dette betyr å trekke ut alle SOAP og XML - RPC svarene du får fra serveren. For eksempel, Hvis du tar noe webtjenesteverktøy som POSTMAN eller PARASOFT, vil du oppdage at det under HTTP-headerbehandleren er et alternativ å angi verdien på innholdstypen. Verdien kan settes til applikasjonen / JSON slik at den trekker ut alle REST (siden SOAP-tjenester ikke støtter alternativene for HTTP-headerbehandling). Dermed kan du sende innholdstypen: Application / XML i en nyttelast seg selv i form av XML. Dette vil også trekke ut SOAP og XML-RPC.
Disse tre faktorene utgjør sikkerhetstjeneste for Web Services for å takle de eksterne angrepene.
Arkitekturen til SOAP-tjenesten
Hver SOAP-tjeneste er avhengig av tre enheter som til slutt danner arkitekturen til SOAP Service.
- Tjenesteleverandør: Alle programvaresystemer eller applikasjoner som er en del eller som tilbyr Web Service.
- Tjenesteforespørsel: Alle programvaresystemer eller applikasjoner som er en del av forespørsler om nettjeneste fra tjenesteleverandøren.
- Tjenestregister: Et register eller lager hvor all informasjon om Web Service leveres av tjenesteleverandøren. (Allerede diskutert i UDDI)
Forklaring
Disse tre enhetene samhandler med hverandre for å gjennomføre en vellykket implementering av Web Service. Dette gjøres i tre faser. Den første fasen er Publisere() fase der en tjenesteleverandør mater alle detaljene om en webtjeneste i et tjeneregister eller lager.
Den andre fasen er Finne() der en tjenesteforespørsel hovedsakelig finner klientapplikasjonen detaljene om webservice fra et lager (har også WSDL XML-fil). Den siste fasen er Bindende () der klientapplikasjonen eller tjenesteforespøreren synkroniseres med tjenesteleverandøren for den endelige implementeringen av nettjenesten.
# 2) RESTful Service
REST står for Representational State Transfer som er en Statsløs Service.
Det kalles statsløs, da webserveren ikke lagrer informasjon om klientsesjonen (varighet til klientapplikasjonen er koblet til og i utførelse), noe som betyr at hver forespørselstype behandles og utføres enkelt ved hjelp av REST-innebygde metoder som GET, POST, TILPASSET (PUT), SLETT, HEAD og så videre.
Faktisk er disse metodene ikke til stede i SOAP.
Metode eller verb
Hver metode i REST har sin betydning. Nedenfor er orienteringen om hver av dem.
- FÅ: Denne metoden brukes til å hente informasjonen som sendes til serveren ved hjelp av en av metodene som PUT eller POST. Dette har ikke et anmodningsorgan. Vellykket utførelse vil gi deg 200 responsobjekter.
- POST: Denne metoden brukes til å opprette et dokument eller en post ved å bruke en forespørselstekst, spesifisert URL, dokumentnøkkel, kontekstnøkkel, etc. Det samme kan hentes ved hjelp av GET-metoden. Vellykket utførelse vil gi deg et 201-svar.
- SETTE: Dette er under CUSTOM-alternativet som er tilgjengelig i POSTMAN eller PARASOFT. Denne metoden brukes til å oppdatere alle dokumenter eller poster som allerede er til stede. Vellykket gjennomføring vil gi deg 201 eller 200 svar.
- SLETT: Denne metoden brukes til å slette alle poster. Vellykket utførelse vil gi deg 204 svar (uten innhold).
Merk: HTTP-responskodene avhenger av hvordan utviklere kode og kan manipuleres til tider. Vi har listet opp de vanlige responskodene som vi får fra hver metodetype.
Arkitekturen til REST-tjenesten
Arkitekturen til REST-tjenesten avhenger av to enheter, det vil si tjenesteforbruker eller rekvirent og tjenesteleverandør. Tjenesteforbrukeren er den som benytter seg av nettjenesten og tjenesteleverandøren, er samlingen av programvare eller system som tilbyr nettjenesten.
Klientapplikasjonen som vanligvis er en tjenesteforbruker bruker innebygde metoder for REST, en URL eller URI, en HTTP-versjon og en nyttelast (hvis den støttes av metoden).
SOAP vs REST
Selv om disse to typer webtjenester brukes til å utføre forespørselen og svaret, er de helt forskjellige i måten de opererer på.
Forskjellene deres er oppført som referanse.
- SOAP-konvolutt kan brukes i REST, men ikke omvendt. F.eks. Et brukertoken som er opprettet i SOAP, kan sendes i REST-forespørselen under HTTP-headerbehandling -> Autorisasjon.
- SOAP er vanligvis sikrere enn REST-tjenester, ettersom SOAP-tjenester gir WSS bortsett fra SSL. Denne SSL er tilstede både i SOAP og REST.
- SOAP er tregere enn REST ettersom forespørselsbehandlingen tar mer tid i SOAP på grunn av XML-dataformatet. REST bruker JSON som er veldig lettvektet og dermed gjør det raskere.
- SOAP har ingen innebygd metode, men REST har GET, PUT, POST, etc.
- SOAP er statlig mens REST er statsløs.
- Forespørselen og svarorganene i SOAP støtter bare XML-dataformatet. I REST støtter forespørselen og svarorganene mange dataformater som JSON, XML, vanlig tekst, etc.
Konklusjon
Denne opplæringen om webtjenester forklarte arkitekturen, komponentene og typene av webtjenester.
Vi lærte også om forskjeller mellom SOAP og REST-tjenester, sammen med andre viktige konsepter og terminologier relatert til Web Services.
Vi håper at denne veiledningen hjalp deg med å forstå Web Services !!
PREV Opplæring | NESTE veiledning
Anbefalt lesing
- Python DateTime Tutorial med eksempler
- Java SWING Tutorial: Container, Components and Event Handling
- HTML Injection Tutorial: Typer og forebygging med eksempler
- Unix Shell Scripting Tutorial med eksempler
- Selen Find Element By Text Tutorial med eksempler
- Python hovedfunksjonsveiledning med praktiske eksempler
- Pairwise Testing eller All-Pairs Testing Tutorial med verktøy og eksempler
- Konfigurasjonstestveiledning med eksempler