RESTful Web Services-opplæring: Eksempel på REST API

Hvorfor bruke Restful Web Services?

Før vi utforsker de tekniske detaljene, hjelper det å forstå hvorfor REST ble så populært. RESTful Web Services ble fremtredende av følgende grunner:

1. Heterogene språk og miljøer – Dette er en av de grunnleggende grunnene, som er den samme som vi har sett for SOAP også.

• Det gjør det mulig for webapplikasjoner som er bygget på forskjellige programmeringsspråk å kommunisere med hverandre.
• Med hjelp fra Restful-tjenester kan disse webapplikasjonene befinne seg i forskjellige miljøer; noen kan være på Windows, og andre kan være på Linux.

Til syvende og sist, uansett hvilket miljø det er, bør resultatet alltid være det samme: applikasjonene bør kunne kommunisere med hverandre. Restful webtjenester tilbyr denne fleksibiliteten til applikasjoner bygget på ulike programmeringsspråk og plattformer.

Bildet nedenfor viser et eksempel på en webapplikasjon som har et krav om å kommunisere med andre applikasjoner som Facebook, Twitter og Google.

Hvis en klientapplikasjon måtte fungere med nettsteder som Facebook og Twitter, ville utviklerne vanligvis trenge å vite hvilket språk og hvilken plattform disse nettstedene var bygget på. Basert på det kunne de skrive grensesnittkoden, men denne tilnærmingen kunne vise seg å være et mareritt å vedlikeholde.

I stedet, Facebook, Twitter og Google eksponere funksjonaliteten deres i form av Restful-webtjenester. Dette lar enhver klientapplikasjon kalle disse webtjenestene via REST, uavhengig av underliggende teknologi.

2. Hendelsen av enheter – Nå for tiden må alt jobbes videre Mobil enheter, enten det er en mobiltelefon, en bærbar PC eller til og med et bilsystem.

Tenk deg hvor mye innsats det krever å kode applikasjoner på disse enhetene for å kommunisere med vanlige webapplikasjoner. Igjen, Restful API-er gjør denne jobben enklere fordi, som nevnt i punkt én, trenger du egentlig ikke å vite det underliggende laget på enheten.

3. Skyens hendelse – Alt flyttes til skyen. Applikasjoner flyttes sakte til skybaserte systemer som Azure or Amazon. Azure og Amazon tilby mange API-er basert på Restful-arkitekturen. Derfor må applikasjoner nå utvikles på en slik måte at de er kompatible med skyen. Siden alle skybaserte arkitekturer fungerer etter REST-prinsippet, er det fornuftig at webtjenester programmeres på en REST-basert arkitektur for å få best mulig utnyttelse av skytjenester.

RESTful nøkkelelementer

REST-webtjenester har kommet langt siden oppstarten. I 2002 ga Web-konsortiet ut definisjonen av WSDL- og SOAP-webtjenester. Dette dannet standarden for hvordan webtjenester ble implementert.

I 2004 ga nettkonsortiet også ut definisjonen av en tilleggsstandard kalt RESTful. I løpet av de siste årene har denne standarden blitt ganske populær og brukes nå av mange av de mest populære nettstedene rundt om i verden, inkludert Facebook og Twitter.

REST er en måte å få tilgang til ressurser som ligger i et bestemt miljø. For eksempel kan du ha en server som er vert for viktige dokumenter, bilder eller videoer. Alle disse er eksempler på ressurser. Hvis en klient, for eksempel en nettleser, trenger noen av disse ressursene, må den sende en forespørsel til serveren. REST-tjenester definerer en standard måte å få tilgang til disse ressursene på.

Nøkkelelementene i en RESTful implementering er som følger:

1. Ressurser – Det første nøkkelelementet er selve ressursen. La oss anta at en webapplikasjon på en server har poster over flere ansatte. La oss anta at URL av webapplikasjonen er https://demo.guru99.comFor å få tilgang til en ansattjournalressurs via REST-tjenester kan man nå bruke kommandoen https://demo.guru99.com/employee/1Denne kommandoen ber webserveren om å oppgi detaljene til den ansatte med ansattnummer 1.
2. Be om verb – Disse beskriver hva du vil gjøre med ressursen. En nettleser bruker et GET-verb for å instruere endepunktet om at det vil hente data. Det finnes imidlertid mange andre verb tilgjengelig, inkludert POST, PUT og DELETE. Så, i tilfellet med eksemplet https://demo.guru99.com/employee/1, nettleseren utsteder faktisk et GET-verb fordi den ønsker å hente detaljene i ansattposten.
3. Be om overskrifter – Dette er tilleggsinstruksjoner som sendes med forespørselen. De kan definere hvilken type svar som kreves eller autorisasjonsdetaljene.
4. Forespørselsorgan – Dette er dataene som sendes med forespørselen. Data sendes vanligvis i forespørselsteksten når en POST-forespørsel sendes til REST-webtjenesten. I et POST-kall forteller klienten REST-webtjenesten at den ønsker å legge til en ressurs på serveren. Forespørselsteksten vil derfor ha detaljene om ressursen som må legges til.
5. Responsorgan – Dette er hoveddelen av svaret. Så, i vårt RESTful API-eksempel, hvis vi skulle spørre webserveren via forespørselen https://demo.guru99.com/employee/1, kan webserveren returnere et XML-dokument med alle detaljene om den ansatte i svarinnholdet.
6. Responsstatuskoder – Dette er de generelle kodene som returneres sammen med svaret fra webserveren. Et eksempel er kode 200, som vanligvis returneres når det ikke er noen feil under retur av et svar til klienten.

Avslappende metoder

Diagrammet nedenfor viser de fleste verbene (POST, GET, PUT og DELETE) og et REST API-eksempel på hva de ville bety.

La oss anta at vi har en RESTful webtjeneste definert på lokasjonen https://demo.guru99.com/employeeNår klienten sender en forespørsel til denne webtjenesten, kan den spesifisere et hvilket som helst av de vanlige HTTP-verbene GET, POST, DELETE og PUT. Nedenfor ser du hva som ville skjedd hvis de respektive verbene ble sendt av klienten.

1. POST – Dette ville bli brukt til å opprette en ny ansatt ved hjelp av RESTful-webtjenesten.
2. GET – Dette ville bli brukt til å få en liste over alle ansatte som bruker RESTful-nettjenesten.
3. PUT – Dette ville bli brukt til å oppdatere alle ansatte som bruker RESTful-nettjenesten.
4. SLETT – Dette ville bli brukt til å slette alle ansatte som bruker RESTful-tjenesten.

La oss nå se på det fra perspektivet til bare én enkelt post. La oss si at det fantes en ansattpost med ansattnummer 1. Følgende handlinger ville ha sine respektive betydninger.

1. POST – Dette ville ikke være aktuelt, siden vi henter data for ansatt 1, som allerede er opprettet.
2. GET – Dette ville bli brukt til å hente detaljene til den ansatte med ansattnummer 1 ved hjelp av RESTful-webtjenesten.
3. PUT – Dette ville bli brukt til å oppdatere detaljene til den ansatte med ansattnummer 1 ved hjelp av RESTful-webtjenesten.
4. SLETT – Dette brukes til å slette detaljene til den ansatte med ansattnummer 1.

Avslappende Architecture

En applikasjon eller arkitektur som anses som RESTful eller REST-stil har følgende egenskaper.

1. Tilstand og funksjonalitet er delt inn i distribuerte ressurser – Dette betyr at alle ressurser skal være tilgjengelige via de vanlige HTTP-kommandoene GET, POST, PUT eller DELETE. Så hvis noen ønsker å hente en fil fra en server, skal de kunne sende GET-forespørselen og hente filen. Hvis de vil legge en fil på serveren, skal de kunne sende enten POST- eller PUT-forespørselen. Til slutt, hvis de vil slette en fil fra serveren, kan de sende DELETE-forespørselen.

2. Arkitekturen er klient/server, statsløs, lagdelt og støtter mellomlagring.

• Klient-server er den typiske arkitekturen der serveren kan være webserveren som er vert for applikasjonen, og klienten kan være like enkel som nettleseren.
• Stateless betyr at tilstanden til applikasjonen ikke opprettholdes i REST. Hvis du for eksempel sletter en ressurs fra en server ved å bruke DELETE-kommandoen, kan du ikke forvente at sletteinformasjonen sendes til neste forespørsel.

For å sikre at ressursen slettes, må du sende GET-forespørselen. GET-forespørselen brukes først til å hente alle ressursene på serveren, hvoretter man må se om ressursen faktisk ble slettet.

AVSLUTTENDE prinsipper og begrensninger

REST-arkitekturen er basert på noen få egenskaper, som er utdypet nedenfor. Enhver RESTful-webtjeneste må overholde egenskapene nedenfor for å kunne kalles RESTful. Disse egenskapene er også kjent som designprinsipper som må følges når man arbeider med RESTful-baserte tjenester.

1. RESTFul Client-Server

   

Dette er det mest grunnleggende kravet til en REST-basert arkitektur. Det betyr at serveren vil ha en RESTful webtjeneste som gir klienten den nødvendige funksjonaliteten. Klienten sender en forespørsel til webtjenesten på serveren. Serveren avviser deretter forespørselen eller etterkommer den og gir klienten et tilstrekkelig svar.

2. statsløs

Konseptet med statsløshet betyr at det er opp til klienten å sørge for at all nødvendig informasjon blir gitt til serveren. Dette er nødvendig slik at serveren kan behandle svaret på riktig måte. Serveren skal ikke beholde noen form for informasjon mellom forespørsler fra klienten. Det er en veldig enkel, uavhengig spørsmål-svar-sekvens. Klienten stiller et spørsmål, og serveren svarer på det på riktig måte. Når klienten stiller et nytt spørsmål, vil ikke serveren huske det forrige spørsmål-svar-scenarioet og må svare på det nye spørsmålet uavhengig.

3. Cache

Cache-konseptet hjelper med problemet med statsløshet beskrevet i forrige punkt. Siden hver server-klient-forespørsel er uavhengig av natur, kan klienten noen ganger be serveren om den samme forespørselen igjen, selv om den allerede har bedt om den tidligere. Denne forespørselen vil gå til serveren, og serveren vil gi et svar, noe som øker trafikken over nettverket. Cache er et konsept implementert på klienten for å lagre forespørsler som allerede er sendt til serveren. Så hvis den samme forespørselen gis av klienten, i stedet for å gå til serveren, vil den gå til cachen og hente den nødvendige informasjonen. Dette sparer mengden frem-og-tilbake nettverkstrafikk fra klienten til serveren.

4. Lagdelt system

Konseptet bak et lagdelt system er at ethvert tilleggslag, for eksempel et mellomvarelag, kan settes inn mellom klienten og den faktiske serveren som er vert for RESTFul-webtjenesten. (Mellomvarelaget er der all forretningslogikken opprettes. Dette kan være en ekstra tjeneste som klienten samhandler med før den foretar et kall til webtjenesten.) Men introduksjonen av dette laget må være transparent slik at det ikke forstyrrer samhandlingen mellom klienten og serveren.

5. Grensesnitt/Uniform Contract

Dette er den underliggende teknikken for hvordan RESTful-webtjenester skal fungere. RESTful fungerer i utgangspunktet på HTTP-weblaget og bruker nøkkelverbene nedenfor for å jobbe med ressurser på serveren.

• POST – For å opprette en ressurs på serveren.
• GET – For å hente en ressurs fra serveren.
• PUT – For å endre tilstanden til en ressurs eller for å oppdatere den.
• SLETT – For å fjerne eller slette en ressurs fra serveren.

REST vs SOAP: Viktige forskjeller

Utviklere veier ofte REST opp mot SOAP når de designer en webtjeneste. Begge tillater distribuerte applikasjoner å kommunisere, men de skiller seg sterkt i filosofi. REST er en arkitekturstil som bruker enkle HTTP-verb og lette formater som JSON, mens SOAP er en streng protokoll som er avhengig av XML-konvolutter og en formell kontract. Tabellen nedenfor oppsummerer de viktigste forskjellene.

I praksis er REST standardvalget for offentlige web- og mobil-API-er fordi det er raskere og enklere å bruke, mens SOAP fortsatt er nyttig for bedriftssystemer som krever innebygd sikkerhet og formell kontroll.tracts.

Lag din første Restful-webtjeneste i ASP.NET

I denne REST API-opplæringen skal vi nå lære hvordan du oppretter en Restful-webtjeneste i ASP.NET.

Webtjenester kan opprettes på en rekke språk, og mange integrerte utviklingsmiljøer kan brukes til å lage REST-baserte tjenester.

I dette RESTful API-eksemplet skal vi opprette REST-applikasjonen vår i .NET ved hjelp av Visual Studio. Vi skal ha en Restful-webtjeneste som vil fungere på datasettet nedenfor.

Datasettet nedenfor representerer et REST API-eksempel på et selskap som eksponerer veiledningene de har basert på Tutorialid.

I vårt REST API-opplæringseksempel skal vi implementere Restful-verbene nedenfor.

1. FÅ veiledning – Når en klient starter dette Restful API-et, vil de få hele settet med veiledninger som er tilgjengelige fra webtjenesten.
2. FÅ Tutorial/Tutorialid – Når en klient starter dette Restful API-et, vil de få navnet på opplæringen basert på Tutorialid-en som er sendt av klienten.
3. POST veiledning/opplæringsnavn – Når en klient starter dette Restful API-et, vil klienten sende en forespørsel om å sette inn et Tutorialname. Nettjenesten vil deretter legge til det innsendte tutorialnavnet i samlingen.
4. SLETT Opplæring/Tutorialid – Når en klient starter dette Restful API-et, vil klienten sende en forespørsel om å slette et Tutorialname basert på Tutorialid. Nettjenesten vil deretter slette det innsendte tutorialnavnet fra samlingen.

La oss følge trinnene nedenfor for å opprette vår første RESTful-webtjeneste, som utfører implementeringen ovenfor.

Hvordan lage din første avslappende webtjeneste

Trinn 1) Opprett et nytt prosjekt.
Det første trinnet er å lage en tom Asp.Net webapplikasjon. Fra Visual Studio 2013 klikker du på menyalternativet Fil->Nytt prosjekt.

Når du klikker på alternativet Nytt prosjekt, vil Visual Studio vise deg en ny dialogboks der du kan velge prosjekttype og legge inn nødvendige detaljer. Dette forklares i neste trinn.

Trinn 2) Skriv inn prosjektnavnet og plasseringen.

1. Sørg for at du først velger C# Nettmal for ASP.NET-nettapplikasjonen. Prosjektet må være av denne typen for å kunne opprette et nettjenesteprosjekt. Ved å velge dette alternativet vil Visual Studio utføre de nødvendige trinnene for å legge til de nødvendige filene for enhver nettbasert applikasjon.
2. Gi prosjektet et navn, som i vårt tilfelle er «Webservice.REST».
3. Sørg deretter for å oppgi et sted der prosjektfilene skal lagres.

Når du er ferdig, vil du se prosjektfilen som ble opprettet i løsningsutforskeren i Visual Studio 2013.

Trinn 3) Opprett webtjenestefilen.
Det neste trinnet er å opprette webtjenestefilen som skal inneholde RESTful-webtjenesten.

1. Først høyreklikker du på prosjektfilen som vist nedenfor.

2. I dette trinnet
   1. Høyreklikk på prosjektfilen.
   2. Velg alternativet «Legg til –> Nytt element».

I dialogboksen som vises, må du gjøre følgende.

1. Velg alternativet WCF-tjeneste (Ajax-aktivert). Hvis du velger en fil av denne typen, legger Visual Studio til grunnleggende kode som hjelper deg med å opprette en RESTful webtjeneste. WCF står for Windows Kommunikasjon FoundationWCF er et bibliotek for applikasjoner fra ulike plattformer (eller samme plattform) for å kommunisere over ulike protokoller som TCP, HTTP og HTTPS. Ajax er asynkron. JavaScript og XML. AJAX lar nettsider oppdateres asynkront ved å utveksle små mengder data med serveren bak kulissene.
2. Deretter gir du tjenesten et navn, som i vårt tilfelle er TutorialService.
3. Til slutt klikker du på Legg til-knappen for å legge til tjenesten i løsningen.

Trinn 4) Lag en konfigurasjon.
Neste trinn er å gjøre en konfigurasjonsendring for å aktivere dette prosjektet til å fungere med RESTful-webtjenester. Dette krever en endring i filen som heter Web.configDenne filen vises i samme vindu som Webservice-prosjektfilen. Filen Web.config inneholder alle konfigurasjonene som gjør at webapplikasjonen fungerer som den skal. Endringen som gjøres, lar applikasjonen sende og motta data som en ren RESTful webtjeneste.

1. Klikk på Web.config-filen for å åpne koden.

2. Finn linjen .

3. Endre linjen til .

Trinn 5) Legg til koden vår for implementering.
Neste steg er å legge til koden vår for implementering. All koden nedenfor må skrives i TutorialService.svc-filen.

1. Den første biten er å legge til kode som representerer dataene våre, som skal brukes i programmet vårt. Så vi skal ha en liste med strengvariabler med verdiene «Arrays», «Queues» og «Stacks». Dette vil representere navnene på veiledningsfilene som er tilgjengelige gjennom webhotelltjenesten vår.

namespace Webservice.REST
{
[ServiceContract(Namespace = "")]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class TutorialService
{
private static List<String> lst = new List<String>
(new String[] {"Arrays","Queues","Stacks"});

Trinn 6) Definer koden for GET-metoden vår.
Deretter definerer vi koden for GET-metoden vår. Denne koden vil også ligge i den samme TutorialService.svc-filen. Denne koden vil kjøres hver gang vi kaller tjenesten fra nettleseren vår.

Metoden nedenfor vil bli brukt for å oppfylle scenariet nedenfor.

• Hvis en bruker ønsker en liste over alle tilgjengelige veiledninger, må koden nedenfor skrives for å oppnå dette.

[WebGet(UriTemplate = "/Tutorial")]

public String GetAllTutorial()
{
    int count = lst.Count;
    String TutorialList = "";
    for (int i = 0; i < count; i++)
        TutorialList = TutorialList + lst[i] + ",";
    return TutorialList;
}

Code Forklaring:-

1. Den første kodelinjen er den viktigste. Den brukes til å definere hvordan vi kan kalle denne metoden via en URLSå, hvis lenken til nettjenesten vår er http://localhost:52645/TutorialService.svc og vi legger til '/Tutorial' til URL, som i http://localhost:52645/TutorialService.svc/Tutorial, vil koden ovenfor bli kalt. Attributtet 'WebGet' er en parameter som tillater at denne metoden er en RESTful-metode, slik at den kan kalles via GET-verbet.
2. Denne delen av koden brukes til å gå gjennom listen vår over strenger i 'lst'-variabelen og returnere alle til det kallende programmet.

Trinn 7) Returner utgangen.
Koden nedenfor sikrer at hvis et GET-kall gjøres til opplæringstjenesten med en opplærings-ID, vil den returnere det tilsvarende opplæringsnavnet basert på opplærings-ID-en.

[WebGet(UriTemplate = "/Tutorial/{Tutorialid}")]

public String GetTutorialbyID(String Tutorialid)
{
    int pid;
    Int32.TryParse(Tutorialid, out pid);
    return lst[pid];
}

Code Forklaring:-

1. Den første kodelinjen er den viktigste. Den definerer hvordan vi kan kalle denne metoden via en URLSå, hvis lenken til nettjenesten vår er http://localhost:52645/TutorialService.svc og vi legger til '/Tutorial/{Tutorialid}' til URL, ville vi kunne kalle webtjenesten som http://localhost:52645/TutorialService.svc/Tutorial/1, for eksempel. Nettjenesten ville da returnere opplæringsnavnet som hadde opplærings-ID-en 1.
2. Denne kodedelen brukes til å returnere opplæringsnavnet som har opplærings-ID-en sendt til webmetoden.

• Som standard må man huske at det som sendes til URL i nettleseren er en streng.
• Men du må huske at indeksen til listen vår må være et heltall, så vi legger til den nødvendige koden for først å konvertere Tutorialid til et heltall.
• Deretter bruker vi den til å få tilgang til indeksposisjonen i listen vår og returnerer verdien til det kallende programmet deretter.

Trinn 8) Skriv koden for POST-metoden.
Neste steg er å skrive koden for POST-metoden vår. Denne metoden vil bli kalt hver gang vi vil legge til en strengverdi i listen over veiledninger via POST-metoden. Hvis du for eksempel vil legge til veiledningsnavnet «Programvaretesting», må du bruke POST-metoden.

[WebInvoke(Method = "POST", RequestFormat = WebMessageFormat.Json,
ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped,
UriTemplate = "/Tutorial/{str}")]

public void AddTutorial(String str)
{
    lst.Add(str);
}

Code Forklaring:-

1. Den første linjen er attributtet «WebInvoke», som er knyttet til metoden vår. Dette gjør at metoden kan kalles via POST-kallet. Attributtene RequestFormat og ResponseFormat må nevnes som JSON, siden verdiene må være i dette formatet når verdier legges ut til en RESTFul-webtjeneste.
2. Den andre kodelinjen brukes til å legge til strengverdien som sendes via POST-kallet til den eksisterende listen over veiledningsstrenger.

Trinn 9) Legg til en metode for å håndtere DELETE-operasjonen.
Til slutt skal vi legge til metoden vår for å håndtere DELETE-operasjonen. Denne metoden vil bli kalt hver gang vi ønsker å slette en eksisterende strengverdi fra listen over veiledninger via DELETE-metoden.

[WebInvoke(Method = "DELETE", RequestFormat = WebMessageFormat.Json,
UriTemplate = "/Tutorial/{Tutorialid}", ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Wrapped)]

public void DeleteTutorial(String Tutorialid)
{
    int pid;
    Int32.TryParse(Tutorialid, out pid);
    lst.RemoveAt(pid);
}

Code Forklaring:-

1. Den første linjen er attributtet «WebInvoke», som er knyttet til metoden vår. Dette gjør at metoden kan kalles via DELETE-kallet. Attributtene RequestFormat og ResponseFormat må oppgis som JSON, siden verdiene må være i dette formatet. Merk at Method-parameteren settes til «DELETE». Dette betyr at hver gang vi bruker DELETE-verbet, vil denne metoden bli kalt.
2. Den andre linjen med kode brukes til å ta Tutorialid sendt via DELETE-anropet og deretter slette den ID-en fra listen vår. (De Int32 funksjonen i koden brukes til å konvertere opplærings-ID-en fra en strengvariabel til et heltall.)

Kjører din første Restful-webtjeneste

Nå som vi har opprettet hele webtjenesten vår i delen ovenfor, la oss se hvordan vi kan kjøre opplæringstjenesten slik at den kan kalles fra hvilken som helst klient.

For å kjøre webtjenesten, følg trinnene nedenfor.

Trinn 1) Høyreklikk på prosjektfilen – Webservice.REST.

Trinn 2) Velg menyalternativet «Angi som oppstartsprosjekt». Dette sikrer at dette prosjektet kjøres når Visual Studio kjører hele løsningen.

Trinn 3) Neste trinn er å kjøre selve prosjektet. Avhengig av hvilken nettleser som er installert som standard på systemet, vil det aktuelle nettlesernavnet vises ved siden av kjør-knappen i Visual Studio. I vårt tilfelle har vi Google Chrome dukker opp. Bare klikk på denne knappen.

Produksjon:-

Når prosjektet kjøres, kan du bla til TutorialService.svc/Tutorial-delen, og du vil få utdataene nedenfor.

I resultatet ovenfor,

• Du kan se at nettleseren kaller «GET»-verbet og utfører «GetAllTutorial»-metoden i webtjenesten. Denne modulen brukes til å vise alle veiledningene som eksponeres av webtjenesten vår.

Tester din første Restful-webtjeneste

I avsnittet ovenfor har vi allerede sett hvordan man bruker nettleseren til å utføre «GET»-verbet og kalle «GetAllTutorial».

1. La oss nå bruke nettleseren til å utføre følgende bruksscenario.

GET Tutorial/Tutorialid – Når en klient starter dette Restful API-et, vil de få navnet på opplæringen basert på Tutorialid-en som er sendt av klienten.

I nettleseren din legger du til strengen /1 etter veiledningsordet i URLHvis du trykker på enter-knappen, får du resultatet nedenfor.

Nå vil du se resultatet av «Køer», som tilsvarer nummer 1 i listen vår over veiledningsstrenger. Dette betyr at metoden «GetTutorialbyID» nå kalles fra webtjenesten vår. Den viser også at verdien 1 sendes via nettleseren til webtjenesten vår og metoden vår, og det er derfor vi får den riktige tilsvarende verdien av «Køer» i nettleseren.

2. La oss deretter bruke webtjenesten vår ved å utføre scenariet nedenfor. For å gjøre dette må du installere verktøyet som heter Fiddler, som er et gratis nedlastbart verktøy.

POST-opplæring/opplæringsnavn – Når en klient starter dette Restful API-et, vil klienten sende en forespørsel om å sette inn et opplæringsnavn. Nettjenesten vil deretter legge til det innsendte opplæringsnavnet i samlingen.

Kjør Fiddler verktøyet og utfør trinnene nedenfor.

1. Gå til skriveseksjonen. Denne brukes til å opprette forespørsler som kan sendes til en hvilken som helst webapplikasjon.
2. Sørg for at forespørselstypen er «POST» og at den er riktig URL blir truffet, noe som i vårt tilfelle burde være http://localhost:52645/TutorialService.svc/Tutorial.
3. Sørg for at innholdstypen er merket som application/json. Husk at POST-forespørselsmetoden vår i webtjenesten vår bare godtar data i JSON-stil, så vi må sørge for at dette er spesifisert når vi sender en forespørsel til applikasjonen vår.
4. Til slutt må vi legge inn dataene våre. Husk at metoden vår for POST godtar en parameter kalt «str». Så her spesifiserer vi at vi vil legge til en verdi kalt «Trær» i samlingen vår av veiledningsnavn og sørge for at den er tagget med variabelnavnet «str».

Til slutt klikker du bare på Utfør-knappen i FiddlerDette vil sende en forespørsel til webtjenesten om å POST dataene «Trær» til webtjenesten vår.

Når vi nå blar til veiledningen URL For å vise alle strengene i veiledningslisten vår, vil du se at verdien «Trees» også er til stede. Dette viser at POST-forespørselen til webtjenesten ble utført og at den ble lagt til veiledningslisten vår.

3. La oss deretter bruke webtjenesten vår ved å utføre scenariet nedenfor. For dette må vi også bruke Fiddler verktøyet.

SLETT Tutorial/Tutorialid – Når en klient starter dette Restful API-et, vil klienten sende en forespørsel om å slette et Tutorialname basert på Tutorialid-en. Nettjenesten vil deretter slette det innsendte tutorialnavnet fra samlingen.

Kjør Fiddler verktøyet og utfør trinnene nedenfor.

1. Gå til skriveseksjonen. Denne brukes til å opprette forespørsler som kan sendes til en hvilken som helst webapplikasjon.
2. Sørg for at forespørselstypen er «SLETT» og at den er riktig URL blir truffet, noe som i vårt tilfelle burde være http://localhost:52645/TutorialService.svc/TutorialSørg for at ID-en som brukes til å slette en streng i listen sendes via URL som en parameter. I vårt REST-eksempel sender vi 1, så dette vil slette 2^nd elementet i samlingen vår, som er «Køer».

Til slutt klikker du bare på Utfør-knappen i FiddlerDette vil sende en forespørsel til webtjenesten om å SLETTE data-"køene" fra webtjenesten vår.

Når vi nå blar til veiledningen URL For å vise alle strengene i veiledningslisten vår, vil du legge merke til at verdien for «Køer» ikke lenger er til stede.

Dette viser at DELETE-forespørselen til webtjenesten ble utført. Elementet med indeksnummer 1 i listen vår over veiledningsstrenger ble slettet.

Beste praksis for RESTful API

Å bygge et REST API som fungerer er bare det første steget; å bygge et som skalerer og forblir vedlikeholdbart krever disiplin. Fremgangsmåtene nedenfor bidrar til å holde endepunktene dine forutsigbare, sikre og enkle for andre utviklere og AI-agenter å bruke.

• Bruk substantiv, ikke verb, i URLs. Endepunkter som f.eks. /ansatte/1 er tydeligere enn /hentAnsatt?id=1, fordi HTTP-verbet allerede beskriver handlingen.
• Returner meningsfulle statuskoder. Send 200 for suksess, 201 for en opprettet ressurs, 400 for en ugyldig forespørsel, 401 for uautorisert tilgang, 404 for en manglende ressurs og 500 for serverfeil.
• Versjonér API-et ditt. Legge til et versjonssegment, for eksempel /v1/ i stien lar deg utvikle tjenesten uten å ødelegge eksisterende kunder.
• Sikre hvert endepunkt. Bruk HTTPS, sammen med API-nøkler eller OAuth 2.0-tokener, og valider all innkommende input.
• Støtter paginering og filtrering. Å returnere store samlinger i sider holder svarene raske og reduserer serverbelastningen.

Å følge disse konvensjonene gjør RESTful-webtjenesten din intuitiv å integrere, enten forbrukeren er en mobilapp, et partnersystem eller en automatisert AI-arbeidsflyt.

Spørsmål og svar