Rest API Tutorial: REST API Architecture And Constraints

rest api tutorial rest api architecture

I denne veiledningen vil vi lære om REST API, webtjenester, arkitektur for REST API, REST API-begrensninger og hvordan du tester et API ved hjelp av POSTMAN:

Forutsetninger: Grunnleggende kunnskap om webtjenester.

Sjekk her for å få en klar forståelse av Web Services.

Hva du vil lære:

• Hva er REST API?
  • Forskjellen mellom SOAP og REST
  • Hvorfor velge REST over SOAP?
    • Hvorfor postbud?
  • REST API-arkitektur
  • REST API-begrensninger
  • Hva er POSTMAN?
  • Hvordan teste API med Postman?
    • Installasjon
• Konklusjon
  • Anbefalt lesing

Hva er REST API?

API er rett og slett et grensesnitt som brukes av programvarekomponenter for å kommunisere med hverandre. En tjeneste er en funksjon som er veldefinert, selvstendig og ikke er avhengig av andre tjenester.

En webtjeneste er en type API, nesten alle opererer via HTTP. Når en Web API er utviklet ved bruk av REST Architecture, kalles den REST Web API.

Per nå er det to typer nettjenester,

• SÅPE
• HVILE

Forskjellen mellom SOAP og REST

Hvorfor velge REST over SOAP?

Nedenfor forklarer du hvorfor du velger REST over SOAP.

• Det er veldig bra for utvikling og testing av web-APIer.
• REST krever mindre båndbredde.
• Vi kan bruke AJAX til de REST-baserte web-API-ene.
• Det krever mindre parsing overhead.
• Nyttelaststørrelsen opprettet av JSON er mindre i størrelse.

Det er mange klienter / verktøy tilgjengelig over nettet, som gjør det mulig for oss å konsumere RESTful Web-tjenester.

De er:

• Postbud
• Advanced Rest Client
• DHC Rest-klient
• Forespørsel
• Søvnløshet
• Påståelig
• Plakat

Hvorfor postbud?

• Den viser alle tilgjengelige alternativer.
• Postman har en tilleggsfunksjon (kjent som Runner).
• Brukervennlig brukergrensesnitt og enkel å bruke.
• Større samfunnsgruppe / medlemmer.

REST API-arkitektur

Det er hovedsakelig nettets arkitektur i en arkitektonisk programvarestil. Det er for distribuerte hypermediasystemer. En RESTful API utnytter direkte HTTP-metoder definert av RFC 2616-protokollen.

Få definisjoner

BRANN står for Application Programming Interface. Det er et sett med definisjoner, protokoller og verktøy for å lage applikasjonsprogramvaren.

Nettjenester er noen programkoder som inneholder data / innebygde metoder. Disse distribueres av organisasjonen over Internett for å kommunisere med brukere, tredjepartsapplikasjoner osv. For kommunikasjon av meldingene brukes mest XML som et meldingssystem. XML koder ganske enkelt all kommunikasjon mellom brukere og applikasjoner.

HTTP betyr Hypertext Transfer Protocol, brukt av World Wide Web. Den definerer hvordan meldinger formateres og overføres, og hvilke handlinger webservere og nettlesere utfører som svar på forskjellige kommandoer.

Arkitektonisk stil, disse er preget av funksjonene som brukes til å skape en struktur og til og med gjøre den unik. Stiler er av to typer: Lagdelt og enhetlig grensesnitt.

HAT : Også kjent som en Uniform Resource Identifier. Den identifiserer en ressurs (tekstdokument, bildefil osv.).
URL: Også kjent som en Uniform Resource Locator. Det er en delmengde av URI-ene, som inkluderer et nettverkssted.
URNE : Også kjent som Uniform Resource Name er en delmengde av URI-er, som inkluderer et navn innenfor et gitt område, men ingen plassering.

For eksempel,

http://elearning.com/amazon/restapi.html#books

Her, i eksemplet ovenfor

HAT : http://elearning.com/amazon/restapi.html#posts
URL : http://elearning.com/amazon/restapi.html
URNE : elearning.com/amazon/restapi.html#posts

hvordan lage en rekke strenger i java

Derfor er en URL en URI som identifiserer en ressurs og også gir midler til å finne ressursen ved å beskrive måten å få tilgang til den.

Så hver URL kan være en URI, men det motsatte er ikke sant.

En RESTful-tjeneste blir eksponert gjennom en Uniform Resource Locator (URL). Dette er et logisk navn som skiller identiteten til ressursen fra det som aksepteres eller returneres.

Et eksempel på REST-arkitektur:

REST API-begrensninger

Et API-grensesnitt sies å være RESTful hvis det oppfyller følgende begrensninger:

• Ensartet grensesnitt: Det betyr, uavhengig av hvilken klient vi bruker, vil det grunnleggende konseptet med å implementere og bruke REST-tjenestene forbli det samme. Alle utviklede REST API-er bør ha en felles tilnærming til utvikling.
• Statsløs: Dette betyr at ingen økt skal lagres. Så, serveren lagrer ikke HTTP-forespørsel sendt av en klient. Derfor for hver server er hver HTTP-forespørsel en ny forespørsel. Uansett, hvor mange ganger forespørselen kommer eller kunden er den unike eller ikke.
• Cacheable: Caching betyr hvor ofte data og svar nås fra en cache i stedet for serveren. Konseptet med caching er aktuelt mens du sender klientforespørselen. Så ytelsesforbedringen gjøres på klientsiden.
• Klient server: Server og klienter er uavhengige av hverandre når det gjelder implementering. En klient trenger bare å sende forespørsels-URI sammen med eller uten godkjenning. Så tar serveren resten av trinnet, det er et svar.
• Lagdelt system: Klienten kan bare sende forespørselen til serveren som ressurs-URI. Men så, før forespørselen sendes til serveren, eksisterer det REST API, som gir oss den lagdelte systemarkitekturen. Det betyr at vi kan ha API distribuert på en server, data distribueres på en annen server og autentisering på en annen server.
• Kode etter behov (valgfritt): Noen ganger kan en klient trenge mer enn bare svaret. REST API lar oss sende en kjørbar kode som et svar (denne kjørbare koden kan være en widget eller hvilken som helst kontroll). Det er imidlertid helt valgfritt om vi har aktivert / implementert denne funksjonen.

Få flere terminologier relatert til Rest API:

Endepunkt : Det er henvisningen til en URL som godtar nettforespørsler. En webtjeneste kan adresseres ved hjelp av sluttpunktreferanse.
For eksempel, Http: // {Domain_URL} //librarygr/libraries.xml

Ressurser : Det er en delmengde av Endpoint. Normalt avslører sluttpunkter noen objekter som kan konsumeres gjennom webtjenester. Ressurser er spesifikt den delen av et objekt over Endpoint URI.
For eksempel, Http: // {Domain_URL} // api / pg_library / ornitologi / svane

Nyttelast : Nyttelast er informasjonen som sendes mens du utfører POST- eller PUT-operasjon. Dette er informasjonen som er spesifisert i brødteksten til HTTP-forespørselen.

Nyttelast sendes i JSON-format, For eksempel,

Parametere :

Vi kan overføre parametere på to måter.

Spørsmålsparametere : Nyttig for å få tilgang til nøkkel- / verdipar i spørringsstrengen til URL-en (delen etter?)

Beste eksempel

http://jsonplaceholder.typicode.com/posts/?id=3

Baneparametere: Det er nyttig å matche en del av URL-en som en parameter. Vi kan sende informasjon som en baneparameter på følgende måte: Form-data, x-www-form-urlencoded, raw, binær.

Beste eksempel:

https://api.github.com/gists/49b05378bb8920d5b4ec54efc27103e2/comments

Hva er POSTMAN?

POSTMAN er en REST-klient, ganske enkelt en app som følger med Chrome-nettleseren. Den blir utviklet, med tanke på utviklere for å gjøre API-samtaltesting enklere. Den har sin egen GUI for å sende API-forespørsler og lese API-svar.

Vi kan utføre REST API-testing både manuelt og automatisk.

I den følgende delen vil vi lære hvordan du tester Web API manuelt ved hjelp av POSTMAN-klienten.

Hvordan teste API med Postman?

Installasjon

Vi trenger tilgang til Chrome nettbutikk . I Chrome-nettleseren søker du etter Postman. Klikk her for å legge den til Chrome-knappen.

Når den er installert, kan vi finne POSTMAN under Chrome-appen. Bare klikk på Postmann-ikonet for å åpne POSTMAN. Det vil ta tid å starte for første gang.

Se følgende URL for å forstå hvordan du bruker POSTBUD som et verktøy.

Forutsetninger: Internett-tilkobling kreves for å få tilgang til tjenester distribuert over nettet. I tilfelle tilgang til tjenestene som er distribuert lokalt, må du sørge for at tilstrekkelige rettigheter blir gitt rettigheter til brukeren som utfører test over POSTMAN.

Dummy Resource URI: I denne opplæringen bruker vi en dummy URI i stedet for en ekte URI. Det vil gi oss svarene som ønsket, men endringer kan ikke gjøres på serveren.

http://jsonplaceholder.typicode.com

Navigasjonstrinn :

#1) Når POSTMAN-appen er lansert, kan vi se forespørselssiden som standard.

hvordan du kjører jar-filer på Windows

#to) Vi kan se listen over API-anrop ved å klikke på rullegardinmenyen. Ved å velge et av alternativene fra rullegardinmenyen, kan vi be om API-anrop til serveren.

# 3) Klikk på knappen Miljøvariabel øverst til høyre på en POSTMAN. Sett det spesifikke miljøet, der vi skal teste. Vi kan lagre den for fremtidig utførelse.

# 4) Det lagrede miljøet kan være tilgjengelig fra rullegardinmenyen Miljø.

# 5) Deretter må vi sette ressurs-URI i den gitte boksen.

# 6) Klikk på Params-knappen ved siden av Ressurs-URI-feltet for å spesifisere spørringsparametere

# 7) Klikk på Autorisasjon-fanen, velg Autorisasjonstype fra rullegardinmenyen og angi ønsket Autorisasjon, eller bare la den være Ingen autorisasjon.

# 8) Klikk på Overskrifter-fanen og angi de nødvendige overskriftene som innholdstype

# 9) Klikk på kategorien Kropp, velg alternativknapp for skjemadata. Spesifiser nødvendige kroppsparametere som må sendes sammen med forespørselens URL

# 10) Klikk på kategorien Body, velg alternativknappen x-www-form-urlencoded. Spesifiser nødvendige kroppsparametere som må sendes som kodet, sammen med forespørselens URL

#elleve) Klikk på fanen Kropp, velg alternativknappen 'rå'. Spesifiser nødvendige kroppsparametere som må sendes sammen med forespørselens URL. Dette er i faktisk JSON-format

# 12) Klikk på kategorien Body, velg alternativknappen ‘binær’. Spesifiser nødvendige kroppsparametere (vanligvis som en fil) som må sendes sammen med forespørselens URL.

# 1. 3) Når vi har konfigurert alle detaljene som spesifisert ovenfor, kan vi nå 'sende' forespørselen. Vi kan også lagre sendeforespørselen som request.json (vi kan endre navnet på forespørselen).

# 14) Vi kan se listen over forespørsler som er gjort, på panelet til venstre under fanen Historikk.

#femten) Vi kan også lagre alle detaljene knyttet til forespørselen (URI, autorisasjon, parametere, brødtekst osv.) Under en eksisterende samling eller en ny samling. Når forespørselen er lagt til samlingen, kan vi eksportere (dele) den og til og med importere en hvilken som helst eksisterende samling.

Vi kan dele samlingen som en lenke, eller som et teambibliotek med en enkel generert kode. Vi kan alltid kjøre hele Collection-pakken.

Selv kan vi publisere nettadressen til samlingen slik at alle som får tilgang til den publiserte nettadressen kan få tilgang til samlingen og konsumere tjenestene som tilbys av Web API.

Det er en funksjon for å logge på POSTMAN, som gjør det mulig for oss å lagre historikk, samlinger, miljødata, lokal lagring slik at vi kan lagre den og få tilgang til den hvor som helst, når som helst etter at vi er logget inn på POSTMAN.

Løper

hvordan åpne en jnlp-fil

Den brukes til å kjøre ressursene i mappen Collections.

Konklusjon

De fleste selskaper bruker REST-arkitektoniske stil for utvikling / implementering av webtjenester fordi det er et enkelt og brukervennlig grensesnitt som krever mindre opplæring for de eksisterende / nye medlemmene av prosjektet. Organisasjoner vurderer REST sammen med sine eksisterende nettjenester.

Les også = >> Flask API Tutorial

I neste opplæring denne REST API-serien, vil vi diskutere forskjellige typer responskoder, typer REST-forespørsler, etc.

Anbefalt lesing

• Rest API-responskoder og typer hvileforespørsler
• POSTMAN-veiledning: API-testing ved hjelp av POSTMAN
• REST API-testing med agurk ved bruk av BDD-tilnærming
• 10 beste API-testverktøy i 2021 (SOAP og REST API-testverktøy)
• REST API-testing med Spring RestTemplate og TestNG
• Slik automatiserer du API-forespørsler ved hjelp av trygg og Jenkins
• Hvordan lage REST-prosjekt i SoapUI Pro: Opplæring # 13
• Parasoft SOAtest Tutorial: Scriptless API Testing Tool