RESTful Web Services-vejledning: Eksempel på REST API

Hvorfor bruge Restful Web Services?

Før vi udforsker de tekniske detaljer, er det nyttigt at forstå, hvorfor REST blev så populært. RESTful Web Services blev fremtrædende af følgende årsager:

1. Heterogene sprog og miljøer – Dette er en af ​​de grundlæggende årsager, hvilket er det samme som det, vi har set for SOAP også.

• Det gør det muligt for webapplikationer, der er bygget på forskellige programmeringssprog, at kommunikere med hinanden.
• Med hjælp fra Restful-tjenester kan disse webapplikationer befinde sig i forskellige miljøer; nogle kan være på Windows, og andre kunne være på Linux.

I sidste ende, uanset hvilket miljø det er, bør resultatet altid være det samme: applikationerne skal kunne kommunikere med hinanden. Restful webtjenester tilbyder denne fleksibilitet til applikationer bygget på forskellige programmeringssprog og platforme.

Billedet nedenfor viser et eksempel på en webapplikation, der skal kunne kommunikere med andre applikationer såsom Facebook, Twitter og Google.

Hvis en klientapplikation skulle fungere med websteder som Facebook og Twitter, ville udviklerne normalt skulle vide, hvilket sprog og hvilken platform disse websteder var bygget på. Baseret på det kunne de skrive grænsefladekoden, men denne tilgang kunne vise sig at være et mareridt at vedligeholde.

I stedet Facebook, Twitter og Google eksponere deres funktionalitet i form af Restful-webtjenester. Dette giver enhver klientapplikation mulighed for at kalde disse webtjenester via REST, uanset den underliggende teknologi.

2. Begivenheden af ​​Enheder – Nu om dage skal alt arbejde videre Mobil enheder, hvad enten det er en mobiltelefon, en bærbar computer eller endda et bilsystem.

Forestil dig den mængde indsats, der kræves for at kode applikationer på disse enheder, så de kommunikerer med normale webapplikationer. Igen gør Restful API'er dette arbejde enklere, fordi du, som nævnt i punkt et, virkelig ikke behøver at kende enhedens underliggende lag.

3. Skyens begivenhed – Alt flytter sig til skyen. Applikationer flytter langsomt til skybaserede systemer som f.eks. Azure or Amazon. Azure og Amazon tilbyde mange API'er baseret på Restful-arkitekturen. Derfor skal applikationer nu udvikles på en sådan måde, at de er kompatible med skyen. Da alle cloudbaserede arkitekturer fungerer efter REST-princippet, giver det mening at programmere webtjenester på en REST-baseret arkitektur for at få mest muligt ud af cloudtjenesterne.

RESTful nøgleelementer

REST-webtjenester har udviklet sig meget siden deres opståen. I 2002 udgav Web-konsortiet definitionen af ​​WSDL- og SOAP-webtjenester. Dette dannede standarden for, hvordan webtjenester blev implementeret.

I 2004 udgav webkonsortiet også definitionen af ​​en yderligere standard kaldet RESTful. I løbet af de seneste år er denne standard blevet ret populær og bruges nu af mange af de mest populære websteder verden over, herunder Facebook og Twitter.

REST er en måde at tilgå ressourcer, der ligger i et bestemt miljø. For eksempel kunne du have en server, der er vært for vigtige dokumenter, billeder eller videoer. Alle disse er eksempler på ressourcer. Hvis en klient, f.eks. en webbrowser, har brug for nogen af ​​disse ressourcer, skal den sende en anmodning til serveren. REST-tjenester definerer en standardmåde, hvorpå disse ressourcer kan tilgås.

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

1. Ressourcer – Det første nøgleelement er selve ressourcen. Lad os antage, at en webapplikation på en server har poster over flere medarbejdere. Lad os antage, at URL af webapplikationen er https://demo.guru99.comFor at få adgang til en medarbejderjournalressource via REST-tjenester kan man nu udføre kommandoen https://demo.guru99.com/employee/1Denne kommando fortæller webserveren, at den skal angive oplysningerne om den medarbejder, hvis medarbejdernummer er 1.
2. Anmod om verber – Disse beskriver, hvad du vil gøre med ressourcen. En browser udsteder et GET-verbum for at instruere endpointen om, at den vil hente data. Der er dog mange andre verber tilgængelige, herunder POST, PUT og DELETE. Så i tilfældet med eksemplet https://demo.guru99.com/employee/1, webbrowseren udsteder faktisk et GET-verbum, fordi den ønsker at hente detaljerne i medarbejderposten.
3. Anmod om overskrifter – Disse er yderligere instruktioner, der sendes med anmodningen. De kan definere den nødvendige svartype eller autorisationsoplysningerne.
4. Anmodningslegeme – Dette er de data, der sendes med anmodningen. Data sendes normalt i anmodningsteksten, når en POST-anmodning sendes til REST-webtjenesten. I et POST-kald fortæller klienten REST-webtjenesten, at den ønsker at tilføje en ressource til serveren. Derfor vil anmodningsteksten indeholde detaljerne om den ressource, der skal tilføjes.
5. Svarorgan – Dette er hoveddelen af ​​svaret. Så hvis vi i vores RESTful API-eksempel skulle forespørge webserveren via anmodningen https://demo.guru99.com/employee/1, kan webserveren returnere et XML-dokument med alle medarbejderens oplysninger i svarteksten.
6. Svarstatuskoder – Dette er de generelle koder, der returneres sammen med svaret fra webserveren. Et eksempel er koden 200, som normalt returneres, når der ikke er nogen fejl under returnering af et svar til klienten.

Afslappende metoder

Diagrammet nedenfor viser de fleste verber (POST, GET, PUT og DELETE) og et REST API-eksempel på, hvad de ville betyde.

Lad os antage, at vi har en RESTful webtjeneste defineret på lokationen https://demo.guru99.com/employeeNår klienten foretager en anmodning til denne webtjeneste, kan den angive et hvilket som helst af de normale HTTP-verber GET, POST, DELETE og PUT. Nedenfor er vist, hvad der ville ske, hvis de respektive verber blev sendt af klienten.

1. POST – Dette ville blive brugt til at oprette en ny medarbejder ved hjælp af RESTful-webtjenesten.
2. GET – Dette ville blive brugt til at få en liste over alle medarbejdere, der bruger RESTful-webtjenesten.
3. PUT – Dette ville blive brugt til at opdatere alle medarbejdere, der bruger RESTful-webtjenesten.
4. SLET – Dette ville blive brugt til at slette alle medarbejdere, der bruger RESTful-tjenesten.

Lad os nu se på det fra et enkelt register. Lad os sige, at der var en medarbejderregistrering med medarbejdernummeret 1. Følgende handlinger ville have deres respektive betydninger.

1. POST – Dette ville ikke være relevant, da vi henter data for medarbejder 1, som allerede er oprettet.
2. GET – Dette ville blive brugt til at hente oplysninger om medarbejderen med medarbejdernummer 1 ved hjælp af RESTful-webtjenesten.
3. PUT – Dette ville blive brugt til at opdatere oplysningerne om medarbejderen med medarbejdernummer 1 ved hjælp af RESTful-webtjenesten.
4. SLET – Dette bruges til at slette oplysningerne om medarbejderen med medarbejdernummer 1.

Rolig Architecture

En applikation eller arkitektur, der betragtes som RESTful eller REST-stil, har følgende karakteristika.

1. Tilstand og funktionalitet er opdelt i distribuerede ressourcer – Det betyder, at alle ressourcer skal være tilgængelige via de normale HTTP-kommandoer GET, POST, PUT eller DELETE. Så hvis nogen ønsker at hente en fil fra en server, skal de kunne udstede GET-anmodningen og hente filen. Hvis de vil lægge en fil på serveren, skal de kunne udstede enten POST- eller PUT-anmodningen. Endelig, hvis de vil slette en fil fra serveren, kan de udstede DELETE-anmodningen.

2. Arkitekturen er klient/server, statsløs, lagdelt og understøtter caching.

• Klient-server er den typiske arkitektur, hvor serveren kan være webserveren, der hoster applikationen, og klienten kan være lige så enkel som webbrowseren.
• Stateless betyder, at applikationens tilstand ikke opretholdes i REST. Hvis du f.eks. sletter en ressource fra en server ved hjælp af kommandoen DELETE, kan du ikke forvente, at sletteinformationen videregives til den næste anmodning.

For at sikre, at ressourcen slettes, skal du udstede GET-anmodningen. GET-anmodningen bruges først til at hente alle ressourcerne på serveren, hvorefter man skal se, om ressourcen rent faktisk er blevet slettet.

RESTFul principper og begrænsninger

REST-arkitekturen er baseret på et par karakteristika, som uddybes nedenfor. Enhver RESTful webtjeneste skal overholde nedenstående karakteristika for at kunne kaldes RESTful. Disse karakteristika er også kendt som designprincipper, der skal følges, når man arbejder med RESTful-baserede tjenester.

1. RESTFul Client-Server

   

Dette er det mest grundlæggende krav til en REST-baseret arkitektur. Det betyder, at serveren har en RESTful webtjeneste, der leverer den nødvendige funktionalitet til klienten. Klienten sender en anmodning til webtjenesten på serveren. Serveren afviser derefter enten anmodningen eller efterkommer den og giver klienten et passende svar.

2. Statsløs

Konceptet "stateless" betyder, at det er op til klienten at sikre, at alle de nødvendige oplysninger leveres til serveren. Dette er nødvendigt for at serveren kan behandle svaret korrekt. Serveren bør ikke gemme nogen form for information mellem anmodninger fra klienten. Det er en meget simpel, uafhængig spørgsmål-svar-sekvens. Klienten stiller et spørgsmål, og serveren besvarer det korrekt. Når klienten stiller et andet spørgsmål, vil serveren ikke huske det forrige spørgsmål-svar-scenarie og skal besvare det nye spørgsmål uafhængigt.

3. Cache

Cache-konceptet hjælper med problemet med statsløshed, der er beskrevet i sidste punkt. Da hver server-klient-anmodning er uafhængig, kan klienten nogle gange bede serveren om den samme anmodning igen, selvom den allerede har bedt om den tidligere. Denne anmodning går til serveren, og serveren giver et svar, hvilket øger trafikken på tværs af netværket. Cachen er et koncept, der er implementeret på klienten for at gemme anmodninger, der allerede er sendt til serveren. Så hvis den samme anmodning gives af klienten, går den i stedet for at gå til serveren til cachen og henter de nødvendige oplysninger. Dette sparer mængden af ​​frem-og-tilbage netværkstrafik fra klienten til serveren.

4. Lagdelt system

Konceptet bag et lagdelt system er, at ethvert ekstra lag, såsom et middleware-lag, kan indsættes mellem klienten og den faktiske server, der hoster RESTFul-webtjenesten. (Middleware-laget er der, hvor al forretningslogikken oprettes. Dette kan være en ekstra tjeneste, som klienten interagerer med, før den foretager et kald til webtjenesten.) Men introduktionen af ​​dette lag skal være transparent, så det ikke forstyrrer interaktionen mellem klienten og serveren.

5. Grænseflade/Ensartet Contract

Dette er den underliggende teknik for, hvordan RESTful webtjenester bør fungere. RESTful fungerer grundlæggende på HTTP-weblaget og bruger nedenstående nøgleord til at arbejde med ressourcer på serveren.

• POST – Opretter en ressource på serveren.
• GET – Henter en ressource fra serveren.
• PUT – At ændre en ressources tilstand eller opdatere den.
• SLET – For at fjerne eller slette en ressource fra serveren.

REST vs. SOAP: Vigtigste forskelle

Udviklere vejer ofte REST op mod SOAP, når de designer en webtjeneste. Begge tillader distribuerede applikationer at kommunikere, men de adskiller sig markant i filosofi. REST er en arkitektonisk stil, der bruger simple HTTP-verber og letvægtsformater som JSON, mens SOAP er en streng protokol, der er afhængig af XML-konvolutter og en formel grænse.tract. Tabellen nedenfor opsummerer de vigtigste forskelle.

I praksis er REST standardvalget for offentlige web- og mobil-API'er, fordi det er hurtigere og nemmere at bruge, mens SOAP stadig er nyttigt til virksomhedssystemer, der kræver indbygget sikkerhed og formel sikkerhed.tracts.

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

I denne REST API-tutorial lærer vi nu, hvordan man opretter en Restful-webtjeneste i ASP.NET.

Webtjenester kan oprettes på en række forskellige sprog, og mange integrerede udviklingsmiljøer kan bruges til at oprette REST-baserede tjenester.

I dette RESTful API-eksempel skal vi oprette vores REST-applikation i .NET ved hjælp af Visual Studio. Vi skal bruge en Restful-webtjeneste, der vil arbejde på nedenstående datasæt.

Datasættet nedenfor repræsenterer et REST API-eksempel på en virksomhed, der eksponerer de tutorials, de har baseret på Tutorialid.

I vores REST API-vejledningseksempel vil vi implementere de restful-verber nedenfor.

1. FÅ vejledning – Når en klient aktiverer denne Restful API, får de vist hele sættet af vejledninger, der er tilgængelige fra webtjenesten.
2. FÅ Tutorial/Tutorialid – Når en klient kalder denne Restful API, får de tildelt et tutorial-navn baseret på det Tutorialid, som klienten har sendt.
3. POST Tutorial/Tutorialnavn – Når en klient kalder denne Restful API, vil klienten indsende en anmodning om at indsætte et Tutorialname. Webtjenesten vil derefter tilføje det indsendte tutorialnavn til samlingen.
4. SLET Tutorial/Tutorialid – Når en klient kalder denne Restful API, vil klienten indsende en anmodning om at slette et Tutorialname baseret på Tutorialid'et. Webtjenesten vil derefter slette det indsendte tutorialnavn fra samlingen.

Lad os følge nedenstående trin for at oprette vores første RESTful webtjeneste, som udfører ovenstående implementering.

Sådan opretter du din første afslappende webtjeneste

Trin 1) Opret et nyt projekt.
Det første trin er at oprette en tom Asp.Net webapplikation. Fra Visual Studio 2013 skal du klikke på menupunktet Filer->Nyt projekt.

Når du klikker på indstillingen Nyt projekt, viser Visual Studio dig en anden dialogboks, hvor du kan vælge projekttypen og indtaste de nødvendige oplysninger. Dette forklares i næste trin.

Trin 2) Indtast projektets navn og placering.

1. Sørg for, at du først vælger C# Webskabelonen til ASP.NET-webapplikationen. Projektet skal være af denne type for at kunne oprette et webserviceprojekt. Ved at vælge denne indstilling udfører Visual Studio de nødvendige trin for at tilføje de nødvendige filer til enhver webbaseret applikation.
2. Giv dit projekt et navn, som i vores tilfælde er “Webservice.REST”.
3. Sørg derefter for at angive en placering, hvor projektfilerne skal gemmes.

Når det er gjort, vil du se den projektfil, der er oprettet i din løsningsbrowser i Visual Studio 2013.

Trin 3) Opret webtjenestefilen.
Det næste trin er at oprette den webservicefil, der skal indeholde RESTful-webservicen.

1. Højreklik først på projektfilen som vist nedenfor.

2. I dette trin,
   1. Højreklik på projektfilen.
   2. Vælg indstillingen "Tilføj->Nyt element".

I den dialogboks, der vises, skal du udføre følgende.

1. Vælg indstillingen WCF Service (Ajax-aktiveret). Hvis du vælger en fil af denne type, tilføjer Visual Studio grundlæggende kode, der hjælper dig med at oprette en RESTful webservice. WCF står for Windows Kommunikation FoundationWCF er et bibliotek til applikationer fra forskellige platforme (eller den samme platform) til at kommunikere over forskellige protokoller såsom TCP, HTTP og HTTPS. Ajax er asynkron. JavaScript og XML. AJAX tillader websider at blive opdateret asynkront ved at udveksle små mængder data med serveren bag kulisserne.
2. Giv derefter tjenesten et navn, som i vores tilfælde er TutorialService.
3. Til sidst skal du klikke på knappen Tilføj for at tilføje tjenesten til løsningen.

Trin 4) Lav en konfiguration.
Det næste trin er at foretage en konfigurationsændring for at aktivere dette projekt til at fungere med RESTful webtjenester. Dette kræver en ændring af filen kaldet Web.configDenne fil vises i samme vindue som Webservice-projektfilen. Filen Web.config indeholder alle de konfigurationer, der får webapplikationen til at fungere som den skal. Ændringen, der foretages, tillader applikationen at sende og modtage data som en ren RESTful webservice.

1. Klik på Web.config-filen for at åbne koden.

2. Find linjen .

3. Ændr linjen til .

Trin 5) Tilføj vores kode til implementering.
Det næste trin er at tilføje vores kode til implementeringen. Al koden nedenfor skal skrives i filen TutorialService.svc.

1. Den første del er at tilføje kode, der repræsenterer vores data, som vil blive brugt i vores program. Vi får altså en liste over strengvariabler med værdierne "Arrays", "Queues" og "Stacks". Dette vil repræsentere navnene på de vejledninger, der er tilgængelige via vores webhostingtjeneste.

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"});

Trin 6) Definer koden for vores GET-metode.
Dernæst definerer vi koden til vores GET-metode. Denne kode vil også være placeret i den samme TutorialService.svc-fil. Denne kode vil køre, hver gang vi kalder tjenesten fra vores browser.

Metoden nedenfor vil blive brugt til at opfylde scenariet nedenfor.

• Hvis en bruger ønsker en liste over alle tilgængelige tutorials, skal nedenstående kode skrives for at opnå 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 kodelinje er den vigtigste. Den bruges til at definere, hvordan vi kan kalde denne metode via en URLSå hvis linket til vores webtjeneste er http://localhost:52645/TutorialService.svc og vi tilføjer '/Tutorial' til URL, som i http://localhost:52645/TutorialService.svc/Tutorial, vil ovenstående kode blive kaldt. Attributten 'WebGet' er en parameter, der tillader denne metode at være en RESTful-metode, så den kan kaldes via GET-verbet.
2. Denne sektion af kode bruges til at gennemgå vores liste over strenge i 'lst'-variablen og returnere dem alle til det kaldende program.

Trin 7) Returner output.
Koden nedenfor sikrer, at hvis et GET-kald foretages til Tutorial-tjenesten med et Tutorial-id, returnerer det det tilsvarende tutorial-navn baseret på Tutorial-id'et.

[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 kodelinje er den vigtigste. Den definerer, hvordan vi kan kalde denne metode via en URLSå hvis linket til vores webtjeneste er http://localhost:52645/TutorialService.svc og vi tilføjer '/Tutorial/{Tutorialid}' til URL, ville vi kunne kalde webtjenesten som http://localhost:52645/TutorialService.svc/Tutorial/1, for eksempel. Webtjenesten ville derefter returnere det vejledningsnavn, der havde vejlednings-id'et 1.
2. Denne del af koden bruges til at returnere navnet på den vejledning, der har det vejlednings-id, der er sendt til webmetoden.

• Som standard skal man huske, at uanset hvad der sendes til URL i browseren er en streng.
• Men du skal huske, at indekset til vores liste skal være et heltal, så vi tilføjer den nødvendige kode til først at konvertere Tutorialid'et til et heltal.
• Vi bruger den derefter til at tilgå indekspositionen i vores liste og returnerer værdien til det kaldende program i overensstemmelse hermed.

Trin 8) Skriv koden til POST-metoden.
Det næste trin er at skrive koden til vores POST-metode. Denne metode vil blive kaldt, hver gang vi ønsker at tilføje en strengværdi til vores liste over tutorials via POST-metoden. Hvis du for eksempel vil tilføje tutorialnavnet "Softwaretestning", skal du bruge 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 linje er attributten 'WebInvoke', som er blevet knyttet til vores metode. Dette gør det muligt at kalde metoden via POST-kaldet. Attributterne RequestFormat og ResponseFormat skal angives som JSON, da værdierne skal være i dette format, når værdier sendes til en RESTFul-webtjeneste.
2. Den anden kodelinje bruges til at tilføje strengværdien, der sendes via POST-kaldet, til vores eksisterende liste over tutorial-strenge.

Trin 9) Tilføj en metode til at håndtere DELETE-operationen.
Endelig tilføjer vi vores metode til at håndtere DELETE-operationen. Denne metode vil blive kaldt, når vi ønsker at slette en eksisterende strengværdi fra vores liste over tutorials 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 linje er attributten 'WebInvoke', som er blevet knyttet til vores metode. Dette gør det muligt at kalde metoden via DELETE-kaldet. Attributterne RequestFormat og ResponseFormat skal angives som JSON, da værdierne skal være i dette format. Bemærk, at Method-parameteren er indstillet til "DELETE". Det betyder, at hver gang vi udsteder DELETE-verbet, vil denne metode blive kaldt.
2. Den anden kodelinje bruges til at tage det Tutorialid, der er sendt via DELETE-opkaldet, og efterfølgende slette det id fra vores liste. (Det Int32 Funktionen i koden bruges til at konvertere Tutorial-id'et fra en strengvariabel til et heltal.)

Kører din første Restful-webtjeneste

Nu hvor vi har oprettet hele vores webtjeneste i afsnittet ovenfor, lad os se, hvordan vi kan køre Tutorial-tjenesten, så den kan kaldes fra enhver klient.

Følg nedenstående trin for at køre webtjenesten.

Trin 1) Højreklik på projektfilen – Webservice.REST.

Trin 2) Vælg menupunktet 'Angiv som opstartsprojekt'. Dette sikrer, at dette projekt køres, når Visual Studio kører hele løsningen.

Trin 3) Det næste trin er at køre selve projektet. Afhængigt af den standardbrowser, der er installeret på systemet, vil det relevante browsernavn vises ved siden af ​​​​kør-knappen i Visual Studio. I vores tilfælde har vi Google Chrome dukker op. Bare klik på denne knap.

Produktion:-

Når projektet er kørt, kan du gå til din TutorialService.svc/Tutorial-sektion, og du vil få outputtet nedenfor.

I outputtet ovenfor,

• Du kan se, at browseren kalder 'GET'-verbet og udfører 'GetAllTutorial'-metoden i webtjenesten. Dette modul bruges til at vise alle de tutorials, der vises af vores webtjeneste.

Test af din første Restful-webtjeneste

I afsnittet ovenfor har vi allerede set, hvordan man bruger browseren til at udføre 'GET'-verbet og kalde 'GetAllTutorial'.

1. Lad os nu bruge browseren til at udføre følgende use case scenario.

GET Tutorial/Tutorialid – Når en klient kalder denne Restful API, får de tildelt et tutorial-navn baseret på det Tutorialid, som klienten har sendt.

I din browser skal du tilføje strengen /1 efter ordet i vejledningen. URLHvis du trykker på Enter-knappen, får du nedenstående output.

Nu vil du se outputtet af "Queues", som svarer til nummer 1 i vores liste over tutorial-strenge. Det betyder, at metoden 'GetTutorialbyID' nu kaldes fra vores webtjeneste. Det viser også, at værdien 1 sendes korrekt via browseren til vores webtjeneste og til vores metode, og det er derfor, vi får den korrekte tilsvarende værdi af "Queues" i browseren.

2. Lad os derefter bruge vores webtjeneste ved at udføre scenariet nedenfor. Til dette skal du installere værktøjet kaldet Fiddler, som er et gratis værktøj, der kan downloades.

POST-vejledning/vejledningsnavn – Når en klient kalder denne Restful API, vil klienten sende en anmodning om at indsætte et vejledningsnavn. Webtjenesten vil derefter tilføje det indsendte vejledningsnavn til samlingen.

Kør Fiddler værktøjet og udfør trinene nedenfor.

1. Gå til afsnittet for oprettelse af forespørgsler. Dette bruges til at oprette anmodninger, der kan indsendes til enhver webapplikation.
2. Sørg for, at anmodningstypen er "POST" og den korrekte URL bliver ramt, hvilket i vores tilfælde burde være http://localhost:52645/TutorialService.svc/Tutorial.
3. Sørg for, at indholdstypen er markeret som application/json. Husk, at vores POST-forespørgselsmetode i vores webtjeneste kun accepterer data i JSON-stil, så vi skal sikre os, at dette er angivet, når vi sender en anmodning til vores applikation.
4. Til sidst skal vi indtaste vores data. Husk, at vores metode til POST accepterer en parameter kaldet 'str'. Så her specificerer vi, at vi vil tilføje en værdi kaldet "Træer" til vores samling af vejledningsnavne og sørge for, at den er tagget med variabelnavnet 'str'.

Klik til sidst blot på knappen Udfør i FiddlerDette vil sende en anmodning til webtjenesten om at POST dataene "Trees" til vores webtjeneste.

Når vi nu går til vejledningen URL For at vise alle strengene i vores vejledningsliste, vil du se, at værdien "Trees" også er til stede. Dette viser, at POST-anmodningen til webtjenesten blev udført, og at den blev tilføjet til vores vejledningsliste.

3. Lad os derefter bruge vores webservice ved at udføre scenariet nedenfor. Til dette skal vi også bruge Fiddler værktøj.

SLET Tutorial/Tutorialid – Når en klient kalder denne Restful API, vil klienten indsende en anmodning om at slette et Tutorialname baseret på Tutorialid. Webtjenesten vil derefter slette det indsendte tutorialnavn fra samlingen.

Kør Fiddler værktøjet og udfør trinene nedenfor.

1. Gå til afsnittet for oprettelse af forespørgsler. Dette bruges til at oprette anmodninger, der kan indsendes til enhver webapplikation.
2. Sørg for, at anmodningstypen er "SLET" og den korrekte URL bliver ramt, hvilket i vores tilfælde burde være http://localhost:52645/TutorialService.svc/TutorialSørg for, at det id, der bruges til at slette en streng i listen, sendes via URL som en parameter. I vores REST-eksempel sender vi 1, så dette vil slette 2^nd element i vores samling, som er "Køer".

Klik til sidst blot på knappen Udfør i FiddlerDette vil sende en anmodning til webtjenesten om at SLETTE data-"køerne" fra vores webtjeneste.

Når vi nu går til vejledningen URL For at vise alle strengene i vores vejledningsliste, vil du bemærke, at værdien af ​​"Køer" ikke længere er til stede.

Dette viser, at DELETE-anmodningen til webtjenesten blev udført. Elementet med indeksnummer 1 i vores liste over vejledningsstrenge blev slettet.

RESTful API Bedste praksisser

At opbygge en REST API, der fungerer, er kun det første skridt; at bygge en, der skalerer og forbliver vedligeholdelsesvenlig, kræver disciplin. Fremgangsmåderne nedenfor hjælper med at holde dine endpoints forudsigelige, sikre og nemme for andre udviklere og AI-agenter at bruge.

• Brug substantiver, ikke verber, i URLs. Endepunkter som f.eks. /medarbejdere/1 er klarere end /hentMedarbejder?id=1, fordi HTTP-verbet allerede beskriver handlingen.
• Returner meningsfulde statuskoder. Send 200 for succes, 201 for en oprettet ressource, 400 for en forkert anmodning, 401 for uautoriseret adgang, 404 for en manglende ressource og 500 for serverfejl.
• Versionér din API. Tilføjelse af et versionssegment, f.eks. /v1/ i stien giver dig mulighed for at udvikle tjenesten uden at ødelægge eksisterende kunder.
• Sikr hvert slutpunkt. Brug HTTPS sammen med API-nøgler eller OAuth 2.0-tokens, og valider alt indgående input.
• Understøtter paginering og filtrering. Returnering af store samlinger i sider holder svarene hurtige og reducerer serverbelastningen.

Ved at følge disse konventioner bliver det intuitivt at integrere din RESTful-webtjeneste, uanset om forbrugeren er en mobilapp, et partnersystem eller en automatiseret AI-workflow.

Ofte Stillede Spørgsmål