rest api tutorial rest api architecture
I denne vejledning lærer vi om REST API, webservices, arkitektur af REST API, REST API-begrænsninger og hvordan man tester en API ved hjælp af POSTMAN:
Forudsætninger: Grundlæggende viden om webservices.
Kontrollere her for at få en klar forståelse af Web Services.
Hvad du lærer:
Hvad er REST API?
API er simpelthen en grænseflade, der bruges af softwarekomponenter til at kommunikere med hinanden. En tjeneste er en funktion, der er veldefineret, selvstændig og ikke afhænger af andre tjenester.
En webservice er en type API, næsten alle fungerer via HTTP. Når en web-API er udviklet ved hjælp af REST-arkitektur, kaldes den REST Web API.
Fra nu af er der to typer webtjenester,
- SÆBE
- HVILE
Forskellen mellem SOAP og REST
SÆBE | HVILE |
---|---|
Vi kan kun bruge XML-format til at sende dataene i anmodningens krop | Vi kan have XML, JSON osv. Format til at sende anmodningen. |
Det er en protokol | Det er en arkitekturstil og uafhængig af enhver protokol, REST kan bruge SOAP Web Services |
Det står for Simple Object Access Protocol | Det står for repræsentativ statsoverførsel |
Det bruger servicegrænseflader til at afsløre forretningslogik. | Det bruger URI til at eksponere forretningslogik. |
SOAP har en streng standard, der skal følges. | Der er ikke nævnt en sådan streng standard, der skal følges af REST. Dog kan brugeren følge nogle få standarder, mens han udvikler webservice ved hjælp af REST. |
Det kræver mere båndbredde. | Det er let. |
Det kan definere sin egen sikkerhed. | REST arver sikkerhedsforanstaltningerne fra transporten. |
Bedste eksempel er Google, AMAZON | Bedste eksempel er YAHOO, LINKEDIN, AMAZON |
SOAP bruger HTTP, SMTP osv. Protokol | REST er kun afhængig af HTTP. |
Reglerne for bindende besked, operationer osv. Er skrevet i WSDL | REST følger WADL-format til beskrivelse af funktionalitet, der tilbydes af webservices |
Det er standardiseret. | REST-tjenester er ikke-standardiserede. |
Det kræver mere læringstid på grund af dets eksisterende regler, bindende osv. | Det kræver mindre tid at lære på grund af dets enkelhed. |
Hvorfor vælge REST over SOAP?
Nedenstående punkter forklarer årsagerne til at vælge REST over SOAP.
- Det er meget godt til udvikling og test af web-API'er.
- REST kræver mindre båndbredde.
- Vi kan bruge AJAX til de REST-baserede web-API'er.
- Det kræver mindre parsing overhead.
- Nyttelaststørrelsen oprettet af JSON er mindre i størrelse.
Der er mange klienter / værktøjer tilgængelige over internettet, hvilket gør det muligt for os at forbruge RESTful Web-tjenester.
De er:
- Postbud
- Avanceret hvileklient
- DHC Rest-klient
- Anmoderen
- Søvnløshed
- Assertible
- Plakat
Hvorfor postbud?
- Det viser alle de tilgængelige indstillinger.
- Postbudmanden har en ekstra funktion (kendt som Runner).
- Brugervenligt brugergrænseflade og nem at bruge.
- Større samfundsgruppe / medlemmer.
REST API-arkitektur
Det er hovedsageligt arkitekturen på Internettet i en software-arkitektonisk stil. Det er til distribuerede hypermediasystemer. En RESTful API drager direkte fordel af HTTP-metoder defineret af RFC 2616-protokollen.
Få definitioner
ILD står for Application Programming Interface. Det er et sæt subrutindefinitioner, protokoller og værktøjer til opbygning af applikationssoftwaren.
Webtjenester er nogle programkoder, der indeholder data / indbyggede metoder. Disse distribueres af organisationen over Internettet til at kommunikere med brugere, tredjepartsapplikationer osv. Til kommunikation af meddelelserne bruges mest XML som et messaging-system. XML koder simpelthen al kommunikation mellem brugere og applikationer.
HTTP betyder Hypertext Transfer Protocol, der bruges af World Wide Web. Den definerer, hvordan meddelelser formateres og transmitteres, og hvilke handlinger webservere og browsere foretager som svar på forskellige kommandoer.
Arkitektonisk stil, disse er kendetegnet ved de funktioner, der bruges til at skabe en struktur og endda gøre den unik. Typografier er af to typer: Lagdelt og ensartet interface.
HAD : Også kendt som en ensartet ressourceidentifikator. Det identificerer en ressource (tekstdokument, billedfil osv.).
URL: Også kendt som en Uniform Resource Locator. Det er en delmængde af URI'erne, der inkluderer en netværksplacering.
URNE : Også kendt som ensartet ressource navn er en delmængde af URI'er, der inkluderer et navn inden for et givet rum, men ingen placering.
For eksempel,
http://elearning.com/amazon/restapi.html#books
Her i ovenstående eksempel
HAD : http://elearning.com/amazon/restapi.html#posts
URL : http://elearning.com/amazon/restapi.html
URNE : elearning.com/amazon/restapi.html#posts
hvordan åbner man en bin-fil
Derfor er en URL en URI, der identificerer en ressource og også giver mulighed for at lokalisere ressourcen ved at beskrive, hvordan man får adgang til den.
Så hver URL kan være en URI, men det modsatte er ikke sandt.
En RESTful-tjeneste eksponeres gennem en Uniform Resource Locator (URL). Dette er et logisk navn, der adskiller identiteten på ressourcen fra det, der accepteres eller returneres.
En prøve REST-arkitektur:
REST API-begrænsninger
En API-grænseflade siges at være RESTful, hvis den opfylder følgende begrænsninger:
- Ensartet grænseflade: Det betyder, uanset hvilken klient vi bruger, det grundlæggende koncept for implementering og brug af REST-tjenesterne forbliver det samme. Alle de udviklede REST API'er skal have en fælles tilgang til udvikling.
- Statsløs: Dette betyder, at der ikke skal gemmes nogen session. Så serveren lagrer ikke nogen HTTP-anmodning sendt af en klient. Derfor for hver server er hver HTTP-anmodning en ny anmodning. Ligegyldigt hvor mange gange anmodningen er fremsat, eller kunden er den unikke eller ej.
- Cacheable: Cache betyder, hvor hyppige data og svar der er adgang til fra en cache i stedet for serveren. Begrebet caching gælder, når du sender klientanmodningen. Så præstationsforbedringen foretages på klientsiden.
- Klient-server: Server og klienter er uafhængige af hinanden med hensyn til implementering. En klient behøver kun at sende anmodningen URI sammen med eller uden godkendelse. Derefter tager serveren resten af trinnet, det er et svar.
- Lagdelte system: Klienten kan kun sende anmodningen til serveren som ressource-URI. Men så, inden anmodningen sendes til serveren, findes der REST API, som giver os den lagdelte systemarkitektur. Det betyder, at vi kan have API implementeret på en server, data distribueres i en anden server og godkendelse på en anden server.
- Kode efter behov (valgfri): Nogle gange har en klient muligvis brug for mere end bare svaret. REST API giver os mulighed for at sende en eksekverbar kode som et svar (denne eksekverbare kode kan være en widget eller en hvilken som helst kontrol). Det er dog helt valgfrit, om vi har aktiveret / implementeret denne funktion.
Få flere terminologier relateret til Rest API:
Slutpunkt : Det er henvisningen til en URL, der accepterer webanmodninger. En webservice kan adresseres ved hjælp af slutpunktsreference.
For eksempel, Http: // {Domain_URL} //librarygr/libraries.xml
Ressourcer : Det er en delmængde af slutpunktet. Normalt udsætter slutpunkter nogle objekter, der kan forbruges via webservices. Ressourcer er specifikt den del af et objekt over Endpoint URI.
For eksempel, Http: // {Domain_URL} // api / pg_library / ornitologi / svane
Nyttelast : Nyttelast er de oplysninger, der sendes under udførelse af POST- eller PUT-operation. Dette er de oplysninger, der er angivet i selve HTTP-anmodningen.
Nyttelast sendes i JSON-format, For eksempel,
{ Id: 1, name:'sam', phones:({title:'mobile',number:9898989899}, {title:'home',number:8888888888}) }
Parametre :
Vi kan overføre parametre på to måder.
Forespørgselsparametre : Nyttigt at få adgang til nøgle- / værdipar i URL-forespørgselsstrengen (delen efter?)
Bedste eksempel
http://jsonplaceholder.typicode.com/posts/?id=3
Sti-parametre: Det er nyttigt at matche en del af URL'en som en parameter. Vi kan sende information som en sti-parameter på følgende måde: Form-data, x-www-form-urlencoded, raw, binær.
Bedste eksempel:
https://api.github.com/gists/49b05378bb8920d5b4ec54efc27103e2/comments
Hvad er POSTMAN?
POSTMAN er en REST-klient, simpelthen en app, der følger med Chrome-browseren. Det udvikles, idet udviklere holdes for øje for at gøre API-opkaldstest nemmere. Det har sin egen GUI til at sende API-anmodninger og læse API-svar.
Vi kan udføre REST API-test både manuelt såvel som ved automatisering.
I det følgende afsnit lærer vi, hvordan man tester Web API manuelt ved hjælp af POSTMAN-klienten.
Sådan testes API med postbud?
Installation
Vi er nødt til at få adgang til Chrome Webshop . I Chrome-browseren søg efter Postman. Klik på her for at føje det til Chrome-knappen.
Når den er installeret, kan vi finde POSTMAN under Chrome-appen. Klik bare på Postmand-ikonet for at åbne POSTMAN. Det tager tid at starte for første gang.
hvordan man installerer svn-plugin i formørkelse
Se følgende URL for at forstå, hvordan du bruger POSTBUD som et værktøj.
Forudsætninger: Internetforbindelse er påkrævet for at få adgang til tjenester, der er distribueret over internettet. I tilfælde af adgang til de tjenester, der er implementeret lokalt, skal du sørge for tilstrækkelige rettigheder, der gives privilegier til den bruger, der udfører test over POSTMAN.
Dummy Resource URI: I denne vejledning bruger vi en dummy URI i stedet for en ægte URI. Det giver os svarene som ønsket, men ændringer kan ikke foretages på serveren.
http://jsonplaceholder.typicode.com
Navigationstrin :
# 1) Når POSTMAN-appen er startet, kan vi se siden Anmodning som standard.
#to) Vi kan se listen over API-opkald ved at klikke på rullemenuen. Ved at vælge en af mulighederne i rullemenuen kan vi anmode om et API-opkald til serveren.
# 3) Klik på knappen Miljøvariabel øverst til højre på en POSTMAN. Indstil det specifikke miljø, hvor vi skal teste. Vi kan gemme det til fremtidig udførelse.
# 4) Det gemte miljø kan fås fra rullemenuen Miljø.
# 5) Dernæst er vi nødt til at indstille ressource-URI i det givne felt.
# 6) Klik på knappen Params ved siden af feltet Resource URI for at specificere forespørgselsparametre
# 7) Klik på fanen Autorisation, vælg Autorisationstype fra rullemenuen, og angiv en hvilken som helst ønsket Autorisation, eller kan blot lade den være Ingen autorisation.
# 8) Klik på fanen Overskrifter, og indstil de ønskede overskrifter som indholdstype
# 9) Klik på fanen Krop, vælg alternativknappen form-data. Angiv krævede brødtekstparametre, der skal sendes sammen med anmodnings-URL'en
# 10) Klik på fanen Krop, vælg alternativknappen x-www-form-urlencoded. Angiv krævede brødtekstparametre, der skal sendes som kodet sammen med anmodnings-URL'en
#elleve) Klik på fanen Krop, vælg alternativknappen 'rå'. Angiv krævede brødtekstparametre, der skal sendes sammen med anmodnings-URL'en. Dette er i faktisk JSON-format
# 12) Klik på fanen Krop, vælg alternativknappen 'binær'. Angiv krævede brødtekstparametre (normalt som en fil), der skal sendes sammen med anmodnings-URL'en.
# 13) Når vi har konfigureret alle detaljerne som angivet ovenfor, kan vi nu 'sende' anmodningen. Vi kan også gemme sendeanmodningen som request.json (vi kan muligvis ændre navnet på anmodningen).
# 14) Vi kan se listen over anmodninger, der er foretaget, i venstre sidepanel under fanen Historie.
gratis registreringsdatabase renere download til Windows 10
#femten) Vi kan også gemme alle detaljer relateret til anmodningen (URI, autorisation, parametre, brødtekst osv.) Under en eksisterende samling eller en ny samling. Når anmodningen er føjet til samlingen, kan vi eksportere (dele) den og endda importere enhver eksisterende samling.
Vi kan dele samlingen som et link eller som et teambibliotek med en simpel genereret kode. Vi kan altid køre hele Collection-pakken.
Selv vi kan offentliggøre samlingens URL til internettet, så enhver, der har adgang til den offentliggjorte URL, kan få adgang til samlingen og forbruge de tjenester, der leveres af Web API.
Der er en funktion til at logge ind på POSTMAN, som gør det muligt for os at gemme historik, samlinger, miljødata, lokal opbevaring, så vi kan gemme det og få adgang til det overalt, når som helst efter at være logget ind på POSTMAN.
Løber
Det bruges til at køre de ressourcer, der findes i mappen Samlinger.
Konklusion
De fleste virksomheder anvender REST-arkitektoniske stil til udvikling / implementering af webtjenester, fordi det er en enkel og brugervenlig grænseflade, der kræver mindre uddannelse for de eksisterende / nye medlemmer af projektet. Organisationer overvejer REST sammen med deres eksisterende webtjenester.
Læs også = >> Flask API-vejledning
I den næste vejledning i denne REST API-serie vil vi diskutere forskellige typer svarkoder, typer REST-anmodninger osv.
Anbefalet læsning
- Rest API-responskoder og typer af hvileanmodninger
- POSTMAN Tutorial: API-test ved hjælp af POSTMAN
- REST API-test med agurk ved hjælp af BDD-tilgang
- 10 bedste API-testværktøjer i 2021 (SOAP og REST API-testværktøjer)
- REST API-test med Spring RestTemplate og TestNG
- Sådan automatiseres API-anmodninger ved hjælp af forsikrede og Jenkins
- Sådan oprettes REST-projekt i SoapUI Pro: Tutorial # 13
- Parasoft SOAtest Tutorial: Scriptless API Test Tool