Handledning för RESTful Web Services: Exempel på REST API

Varför använda Restful Web Services?

Innan vi utforskar de tekniska detaljerna är det bra att förstå varför REST blev så populärt. RESTful Web Services blev framträdande av följande skäl:

1. Heterogena språk och miljöer – Detta är en av de grundläggande orsakerna, vilket är samma som vi har sett för TVÅL också.

• Det gör det möjligt för webbapplikationer som är byggda på olika programmeringsspråk att kommunicera med varandra.
• Med hjälp av Restful-tjänster kan dessa webbapplikationer finnas i olika miljöer; vissa kan vara på Windows, och andra kan vara på Linux.

I slutändan, oavsett vilken miljö det är, bör resultatet alltid vara detsamma: applikationerna ska kunna kommunicera med varandra. Restful webbtjänster erbjuder denna flexibilitet till applikationer byggda på olika programmeringsspråk och plattformar.

Bilden nedan visar ett exempel på en webbapplikation som har ett krav på att kommunicera med andra applikationer som Facebook, Twitter och Google.

Om en klientapplikation skulle behöva fungera med webbplatser som Facebook och Twitter, skulle utvecklarna normalt behöva veta vilket språk och vilken plattform dessa webbplatser byggdes på. Baserat på det skulle de kunna skriva gränssnittskoden, men den här metoden skulle kunna visa sig vara en mardröm att underhålla.

Istället Facebook, Twitter och Google exponera deras funktionalitet i form av Restful-webbtjänster. Detta gör det möjligt för alla klientapplikationer att anropa dessa webbtjänster via REST, oavsett underliggande teknik.

2. Händelsen av Enheter – Nu för tiden måste allt jobbas på Mobil enheter, oavsett om det är en mobiltelefon, en bärbar dator eller till och med ett bilsystem.

Tänk dig hur mycket ansträngning det krävs för att koda applikationer på dessa enheter så att de kommunicerar med vanliga webbapplikationer. Återigen, Restfuls API:er gör det här jobbet enklare eftersom du, som nämnts i punkt ett, egentligen inte behöver känna till enhetens underliggande lager.

3. Molnets händelse – Allt flyttas till molnet. Applikationer flyttas långsamt till molnbaserade system som t.ex. Azure or Amazon. Azure och Amazon tillhandahålla många API:er baserade på Restful-arkitekturen. Därför måste applikationer nu utvecklas på ett sådant sätt att de är kompatibla med molnet. Eftersom alla molnbaserade arkitekturer fungerar enligt REST-principen är det klokt att webbtjänster programmeras på en REST-baserad arkitektur för att utnyttja molntjänsterna på bästa sätt.

RESTful nyckelelement

REST-webbtjänster har utvecklats mycket sedan starten. År 2002 släppte Web Consortium definitionen av WSDL- och SOAP-webbtjänster. Detta bildade standarden för hur webbtjänster implementerades.

År 2004 släppte webbkonsortiet även definitionen av en ytterligare standard som kallas RESTful. Under de senaste åren har denna standard blivit ganska populär och används nu av många av de mest populära webbplatserna runt om i världen, inklusive Facebook och Twitter.

REST är ett sätt att komma åt resurser som finns i en viss miljö. Du kan till exempel ha en server som lagrar viktiga dokument, bilder eller videor. Alla dessa är exempel på resurser. Om en klient, till exempel en webbläsare, behöver någon av dessa resurser måste den skicka en begäran till servern. REST-tjänster definierar ett standardiserat sätt på vilket dessa resurser kan nås.

Nyckelelementen i en RESTful implementering är följande:

1. Resurser – Det första nyckelelementet är själva resursen. Låt oss anta att en webbapplikation på en server har register över flera anställda. Låt oss anta att URL av webbapplikationen är https://demo.guru99.comFör att nu komma åt en resurs för anställdas register via REST-tjänster kan man utfärda kommandot https://demo.guru99.com/employee/1Det här kommandot instruerar webbservern att ange information om den anställde vars anställningsnummer är 1.
2. Begär verb – Dessa beskriver vad du vill göra med resursen. En webbläsare utfärdar ett GET-verb för att instruera slutpunkten att den vill hämta data. Det finns dock många andra verb tillgängliga, inklusive POST, PUT och DELETE. Så, i fallet med exemplet https://demo.guru99.com/employee/1, webbläsaren utfärdar faktiskt ett GET-verb eftersom den vill hämta detaljerna i medarbetarposten.
3. Begär rubriker – Dessa är ytterligare instruktioner som skickas med begäran. De kan definiera vilken typ av svar som krävs eller auktoriseringsuppgifterna.
4. Begäran kropp – Detta är den data som skickas med begäran. Data skickas normalt i begärantexten när en POST-begäran görs till REST-webbtjänsten. I ett POST-anrop meddelar klienten REST-webbtjänsten att den vill lägga till en resurs på servern. Därför skulle begärantexten innehålla information om den resurs som behöver läggas till.
5. Svarsorgan – Detta är huvuddelen av svaret. Så, i vårt RESTful API-exempel, om vi skulle fråga webbservern via begäran https://demo.guru99.com/employee/1, kan webbservern returnera ett XML-dokument med alla detaljer om den anställda i svarstexten.
6. Svarsstatuskoder – Dessa är de allmänna koderna som returneras tillsammans med svaret från webbservern. Ett exempel är koden 200, som normalt returneras när det inte finns något fel vid retur av ett svar till klienten.

Vilsamma metoder

Diagrammet nedan visar de flesta verben (POST, GET, PUT och DELETE) och ett REST API-exempel på vad de skulle betyda.

Låt oss anta att vi har en RESTful webbtjänst definierad på platsen https://demo.guru99.com/employeeNär klienten gör en begäran till den här webbtjänsten kan den ange vilket som helst av de vanliga HTTP-verben GET, POST, DELETE och PUT. Nedan följer vad som skulle hända om respektive verb skickades av klienten.

1. POST – Detta skulle användas för att skapa en ny medarbetare med hjälp av RESTful-webbtjänsten.
2. FÅ – Detta skulle användas för att hämta en lista över alla anställda som använder RESTful-webbtjänsten.
3. SÄTTA – Detta skulle användas för att uppdatera alla anställda som använder RESTful-webbtjänsten.
4. RADERA – Detta skulle användas för att ta bort alla anställda som använder RESTful-tjänsten.

Låt oss nu titta på det ur ett enda register. Låt oss säga att det fanns en medarbetarregister med medarbetarnummer 1. Följande åtgärder skulle ha sina respektive betydelser.

1. POST – Detta skulle inte vara tillämpligt eftersom vi hämtar data för anställd 1, som redan är skapad.
2. FÅ – Detta skulle användas för att hämta information om den anställde med anställningsnummer 1 med hjälp av RESTful-webbtjänsten.
3. SÄTTA – Detta skulle användas för att uppdatera uppgifterna för den anställde med anställningsnummer 1 med hjälp av RESTful-webbtjänsten.
4. RADERA – Detta används för att radera uppgifterna för den anställde med anställningsnummer 1.

Rogivande Architecture

En applikation eller arkitektur som anses vara RESTful eller REST-stil har följande egenskaper.

1. Tillstånd och funktionalitet delas in i distribuerade resurser – Det här betyder att varje resurs ska vara tillgänglig via de vanliga HTTP-kommandona GET, POST, PUT eller DELETE. Så om någon vill hämta en fil från en server ska de kunna utfärda GET-begäran och hämta filen. Om de vill lägga en fil på servern ska de kunna utfärda antingen POST- eller PUT-begäran. Slutligen, om de vill ta bort en fil från servern kan de utfärda DELETE-begäran.

2. Arkitekturen är klient/server, tillståndslös, lagerbaserad och har stöd för cachning.

• Klient-server är den typiska arkitekturen där servern kan vara webbservern som är värd för applikationen, och klienten kan vara lika enkel som webbläsaren.
• Stateless betyder att applikationens tillstånd inte bibehålls i REST. Om du till exempel tar bort en resurs från en server med kommandot DELETE kan du inte förvänta dig att raderingsinformationen ska skickas till nästa begäran.

För att säkerställa att resursen tas bort måste du utfärda GET-begäran. GET-begäran används för att först hämta alla resurser på servern, varefter man behöver se om resursen faktiskt har tagits bort.

ROLIGA principer och begränsningar

REST-arkitekturen är baserad på ett fåtal egenskaper, vilka beskrivs nedan. Alla RESTful-webbtjänster måste uppfylla egenskaperna nedan för att kunna kallas RESTful. Dessa egenskaper är också kända som designprinciper som måste följas när man arbetar med RESTful-baserade tjänster.

1. RESTFul Client-Server

   

Detta är det mest grundläggande kravet för en REST-baserad arkitektur. Det innebär att servern har en RESTful webbtjänst som tillhandahåller den nödvändiga funktionaliteten till klienten. Klienten skickar en begäran till webbtjänsten på servern. Servern avvisar sedan antingen begäran eller går med på den och ger klienten ett adekvat svar.

2. Statslös

Konceptet "stateless" innebär att det är klientens ansvar att säkerställa att all nödvändig information tillhandahålls servern. Detta krävs för att servern ska kunna bearbeta svaret på rätt sätt. Servern bör inte lagra någon form av information mellan förfrågningar från klienten. Det är en mycket enkel, oberoende fråga-svar-sekvens. Klienten ställer en fråga, och servern besvarar den på lämpligt sätt. När klienten ställer en annan fråga kommer servern inte ihåg det föregående fråga-svar-scenariot och kommer att behöva besvara den nya frågan oberoende av varandra.

3. Cache

Cache-konceptet hjälper till med problemet med tillståndslöshet som beskrevs i den sista punkten. Eftersom varje server-klient-förfrågan är oberoende till sin natur kan klienten ibland be servern om samma förfrågan igen, trots att den redan har bett om den tidigare. Denna förfrågan går till servern, och servern ger ett svar, vilket ökar trafiken över nätverket. Cache är ett koncept som implementeras på klienten för att lagra förfrågningar som redan har skickats till servern. Så om samma förfrågan ges av klienten, istället för att gå till servern, går den till cachen och hämtar den information som krävs. Detta sparar mängden fram-och-tillbaka-nätverkstrafik från klienten till servern.

4. System i lager

Konceptet med ett lagersystem är att vilket ytterligare lager som helst, såsom ett mellanprogramlager, kan infogas mellan klienten och den faktiska servern som är värd för RESTFul-webbtjänsten. (Mellanprogramlagret är där all affärslogik skapas. Detta kan vara en extra tjänst som klienten interagerar med innan den gör ett anrop till webbtjänsten.) Men införandet av detta lager måste vara transparent så att det inte stör interaktionen mellan klienten och servern.

5. Gränssnitt/Uniform Contract

Detta är den underliggande tekniken för hur RESTful webbtjänster bör fungera. RESTful fungerar i grunden på HTTP-webblagret och använder nyckelverben nedan för att arbeta med resurser på servern.

• POST – För att skapa en resurs på servern.
• GET – För att hämta en resurs från servern.
• PUT – Att ändra en resurs tillstånd eller uppdatera den.
• TA BORT – För att ta bort eller radera en resurs från servern.

REST vs SOAP: Viktiga skillnader

Utvecklare väger ofta REST mot SOAP när de utformar en webbtjänst. Båda tillåter distribuerade applikationer att kommunicera, men de skiljer sig markant åt i filosofi. REST är en arkitekturstil som använder enkla HTTP-verb och lättviktsformat som JSON, medan TVÅL är ett strikt protokoll som förlitar sig på XML-kuvert och en formell kontext.tract. Tabellen nedan sammanfattar de viktigaste skillnaderna.

I praktiken är REST standardvalet för publika webb- och mobila API:er eftersom det är snabbare och enklare att använda, medan SOAP fortfarande är användbart för företagssystem som kräver inbyggd säkerhet och formell kontroll.tracts.

Skapa din första Restful-webbtjänst i ASP.NET

I den här REST API-handledningen ska vi nu lära oss hur man skapar en Restful-webbtjänst i ASP.NET.

Webbtjänster kan skapas på en mängd olika språk, och många integrerade utvecklingsmiljöer kan användas för att skapa REST-baserade tjänster.

I det här RESTful API-exemplet ska vi skapa vår REST-applikation i .NET med hjälp av Visual Studio. Vi kommer att ha en Restful-webbtjänst som kommer att arbeta med datamängden nedan.

Datauppsättningen nedan representerar ett REST API-exempel på ett företag som exponerar de handledningar de har baserat på Tutorialid.

I vårt REST API-handledningsexempel ska vi implementera Restful-verben nedan.

1. Hämta handledning – När en klient anropar detta Restful API får de tillgång till hela uppsättningen handledningar som finns tillgängliga från webbtjänsten.
2. Hämta handledning/Tutorialid – När en klient anropar detta Restful API kommer de att få handledningsnamnet baserat på det Tutorialid som skickats av klienten.
3. POST Handledning/Tutorialnamn – När en klient anropar detta Restful API skickar klienten en begäran om att infoga ett handledningsnamn. Webbtjänsten lägger sedan till det skickade handledningsnamnet i samlingen.
4. DELETE Tutorial/Tutorialid – När en klient anropar detta Restful API skickar klienten en begäran om att ta bort ett handledningsnamn baserat på Tutorialid. Webbtjänsten tar sedan bort det inskickade handledningsnamnet från samlingen.

Låt oss följa stegen nedan för att skapa vår första RESTful-webbtjänst, som utför ovanstående implementering.

Hur du skapar din första vilsamma webbtjänst

Steg 1) Skapa ett nytt projekt.
Det första steget är att skapa en tom Asp.Net webbapplikation. Från Visual Studio 2013 klickar du på menyalternativet Arkiv->Nytt projekt.

När du klickar på alternativet Nytt projekt visar Visual Studio en annan dialogruta där du kan välja projekttyp och ange nödvändiga uppgifter. Detta förklaras i nästa steg.

Steg 2) Ange projektets namn och plats.

1. Se till att du först väljer C# webbmallen för ASP.NET-webbapplikationen. Projektet måste vara av den här typen för att skapa ett webbtjänstprojekt. Genom att välja det här alternativet kommer Visual Studio att utföra de nödvändiga stegen för att lägga till de filer som krävs för alla webbaserade applikationer.
2. Ge ditt projekt ett namn, vilket i vårt fall är ”Webservice.REST”.
3. Se sedan till att du anger en plats där projektfilerna ska lagras.

När det är klart ser du projektfilen som skapats i din lösningsutforskare i Visual Studio 2013.

Steg 3) Skapa webbtjänstfilen.
Nästa steg är att skapa webbtjänstfilen som ska innehålla RESTful-webbtjänsten.

1. Högerklicka först på projektfilen som visas nedan.

2. I detta steg
   1. Högerklicka på projektfilen.
   2. Välj alternativet "Lägg till->Nytt objekt".

I dialogrutan som visas behöver du göra följande.

1. Välj alternativet WCF-tjänst (Ajax-aktiverad). Om du väljer en fil av den här typen lägger Visual Studio till grundläggande kod som hjälper dig att skapa en RESTful webbtjänst. WCF står för Windows Kommunikation FoundationWCF är ett bibliotek för applikationer från olika plattformar (eller samma plattform) för att kommunicera över olika protokoll som TCP, HTTP och HTTPS. Ajax är asynkront. JavaScript och XML. AJAX tillåter webbsidor att uppdateras asynkront genom att små mängder data utbyts med servern bakom kulisserna.
2. Ange sedan ett namn för tjänsten, vilket i vårt fall är TutorialService.
3. Klicka slutligen på knappen Lägg till för att lägga till tjänsten i lösningen.

Steg 4) Gör en konfiguration.
Nästa steg är att göra en konfigurationsändring för att projektet ska kunna fungera med RESTful webbtjänster. Detta kräver en ändring av filen som heter web.configDen här filen visas i samma fönster som Webservice-projektfilen. Filen Web.config innehåller alla konfigurationer som gör att webbapplikationen fungerar som den ska. Ändringen som görs gör att applikationen kan skicka och ta emot data som en ren RESTful webbtjänst.

1. Klicka på Web.config-filen för att öppna koden.

2. Hitta linjen .

3. Ändra raden till .

Steg 5) Lägg till vår kod för implementering.
Nästa steg är att lägga till vår kod för implementeringen. All kod nedan måste skrivas i filen TutorialService.svc.

1. Den första delen är att lägga till kod som representerar våra data, vilka kommer att användas i vårt program. Vi kommer alltså att ha en lista med strängvariabler med värdena "Arrays", "Queues" och "Stacks". Detta kommer att representera namnen på handledningarna som är tillgängliga via vår webbhotellstjänst.

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

Steg 6) Definiera koden för vår GET-metod.
Härnäst definierar vi koden för vår GET-metod. Denna kod kommer också att finnas i samma TutorialService.svc-fil. Denna kod kommer att köras varje gång vi anropar tjänsten från vår webbläsare.

Metoden nedan kommer att användas för att uppfylla scenariot nedan.

• Om en användare vill ha en lista över alla tillgängliga handledningar, måste koden nedan skrivas för att åstadkomma detta.

[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 Förklaring:-

1. Den första raden i kod är den viktigaste. Den används för att definiera hur vi kan anropa den här metoden via en URLSå, om länken till vår webbtjänst är http://localhost:52645/TutorialService.svc och vi lägger till '/Tutorial' till URL, som i http://localhost:52645/TutorialService.svc/Tutorial, kommer ovanstående kod att anropas. Attributet 'WebGet' är en parameter som gör att den här metoden kan vara en RESTful-metod så att den kan anropas via GET-verbet.
2. Denna kodsektion används för att gå igenom vår lista med strängar i variabeln 'lst' och returnera alla till det anropande programmet.

Steg 7) Returnera utgången.
Koden nedan säkerställer att om ett GET-anrop görs till handledningstjänsten med ett handlednings-ID, returnerar det motsvarande handledningsnamn baserat på handlednings-ID:t.

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

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

Code Förklaring:-

1. Den första raden i kod är den viktigaste. Den definierar hur vi kan anropa den här metoden via en URLSå, om länken till vår webbtjänst är http://localhost:52645/TutorialService.svc och vi lägger till '/Tutorial/{Tutorialid}' till URL, skulle vi kunna anropa webbtjänsten som http://localhost:52645/TutorialService.svc/Tutorial/1, till exempel. Webbtjänsten skulle då returnera handledningsnamnet som hade handlednings-ID 1.
2. Den här koddelen används för att returnera handledningsnamnet som har handlednings-ID:t som skickats till webbmetoden.

• Som standard måste man komma ihåg att allt som skickas till URL i webbläsaren är en sträng.
• Men du måste komma ihåg att indexet till vår lista måste vara ett heltal, så vi lägger till den nödvändiga koden för att först konvertera Tutorialid till ett heltal.
• Vi använder den sedan för att komma åt indexpositionen i vår lista och returnera värdet till det anropande programmet i enlighet därmed.

Steg 8) Skriv koden för POST-metoden.
Nästa steg är att skriva koden för vår POST-metod. Denna metod kommer att anropas varje gång vi vill lägga till ett strängvärde till vår lista med handledningar via POST-metoden. Om du till exempel vill lägga till handledningsnamnet "Programvarutestning" skulle du behöva använda 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 Förklaring:-

1. Den första raden är attributet 'WebInvoke', vilket har kopplats till vår metod. Detta gör att metoden kan anropas via POST-anropet. Attributen RequestFormat och ResponseFormat måste anges som JSON, eftersom värdena måste vara i detta format när värden skickas till en RESTFul-webbtjänst.
2. Den andra kodraden används för att lägga till strängvärdet som skickas via POST-anropet till vår befintliga lista med handledningssträngar.

Steg 9) Lägg till en metod för att hantera DELETE-operationen.
Slutligen ska vi lägga till vår metod för att hantera DELETE-operationen. Denna metod kommer att anropas när vi vill ta bort ett befintligt strängvärde från vår lista med handledningar 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 Förklaring:-

1. Den första raden är attributet 'WebInvoke', vilket har kopplats till vår metod. Detta gör att metoden kan anropas via DELETE-anropet. Attributen RequestFormat och ResponseFormat måste anges som JSON, eftersom värdena måste vara i detta format. Observera att Method-parametern är inställd på "DELETE". Detta innebär att varje gång vi anger DELETE-verbet kommer denna metod att anropas.
2. Den andra raden med kod används för att ta det Tutorialid som skickas via DELETE-anropet och sedan radera det ID:t från vår lista. (De Int32 Funktionen i koden används för att konvertera handlednings-ID:t från en strängvariabel till ett heltal.)

Kör din första Restful-webbtjänst

Nu när vi har skapat hela vår webbtjänst i avsnittet ovan, låt oss se hur vi kan köra handledningstjänsten så att den kan anropas från vilken klient som helst.

För att köra webbtjänsten, följ stegen nedan.

Steg 1) Högerklicka på projektfilen – Webservice.REST.

Steg 2) Välj menyalternativet "Ange som startprojekt". Detta säkerställer att projektet körs när Visual Studio kör hela lösningen.

Steg 3) Nästa steg är att köra själva projektet. Beroende på vilken standardwebbläsare som är installerad på systemet kommer lämpligt webbläsarnamn att visas bredvid körknappen i Visual Studio. I vårt fall har vi Google Chrome dyker upp. Klicka bara på den här knappen.

Produktion:-

När projektet körs kan du bläddra till avsnittet TutorialService.svc/Tutorial, så får du utdata nedan.

I utgången ovan,

• Du kan se att webbläsaren anropar verbet 'GET' och kör metoden 'GetAllTutorial' i webbtjänsten. Den här modulen används för att visa alla handledningar som exponeras av vår webbtjänst.

Testar din första Restful-webbtjänst

I avsnittet ovan har vi redan sett hur man använder webbläsaren för att köra 'GET'-verbet och anropa 'GetAllTutorial'.

1. Låt oss nu använda webbläsaren för att utföra följande användningsfallsscenario.

GET Tutorial/Tutorialid – När en klient anropar detta Restful API får de handledningsnamnet baserat på det Tutorialid som skickats av klienten.

I din webbläsare lägger du till strängen /1 efter ordet i handledningen. URLOm du trycker på Enter-knappen får du utdata nedan.

Nu ser du utdata för "Queues", vilket motsvarar siffran 1 i vår lista över handledningssträngar. Det betyder att metoden 'GetTutorialbyID' nu anropas från vår webbtjänst. Det visar också att värdet 1 skickas framgångsrikt via webbläsaren till vår webbtjänst och till vår metod, och det är därför vi får det korrekta motsvarande värdet för "Queues" i webbläsaren.

2. Nu ska vi använda vår webbtjänst genom att köra scenariot nedan. För detta behöver du installera verktyget som heter Fiddler, vilket är ett gratis nedladdningsbart verktyg.

POST-handledning/handledningsnamn – När en klient anropar detta Restful API skickar klienten en begäran om att infoga ett handledningsnamn. Webbtjänsten lägger sedan till det skickade handledningsnamnet i samlingen.

Kör Fiddler verktyget och utför stegen nedan.

1. Gå till avsnittet för att skapa förfrågningar. Detta används för att skapa förfrågningar som kan skickas till valfri webbapplikation.
2. Se till att begäran är typen ”POST” och att den är korrekt URL blir träffad, vilket i vårt fall borde vara http://localhost:52645/TutorialService.svc/Tutorial.
3. Se till att Content-Type är markerad som application/json. Kom ihåg att vår POST-förfrågningsmetod i vår webbtjänst endast accepterar data i JSON-stil, så vi måste se till att detta anges när vi skickar en förfrågan till vår applikation.
4. Slutligen behöver vi ange våra data. Kom ihåg att vår metod för POST accepterar en parameter som heter 'str'. Så här anger vi att vi vill lägga till ett värde som heter "Trees" till vår samling av handledningsnamn och se till att det är taggat till variabelnamnet 'str'.

Slutligen klickar du bara på knappen Utför i FiddlerDetta skickar en begäran till webbtjänsten om att POSTA data "Trees" till vår webbtjänst.

Nu, när vi bläddrar till handledningen URL För att visa alla strängar i vår handledningslista ser du att värdet för "Trees" också finns. Detta visar att POST-begäran till webbtjänsten har utförts och att den har lagts till i vår handledningslista.

3. Nu ska vi använda vår webbtjänst genom att köra scenariot nedan. För detta behöver vi också använda Fiddler verktyg.

TA BORT Handledning/Handledningsid – När en klient anropar detta Restful API skickar klienten en begäran om att ta bort ett handledningsnamn baserat på handledningsid. Webbtjänsten tar sedan bort det inskickade handledningsnamnet från samlingen.

Kör Fiddler verktyget och utför stegen nedan.

1. Gå till avsnittet för att skapa förfrågningar. Detta används för att skapa förfrågningar som kan skickas till valfri webbapplikation.
2. Se till att begäran är typen "DELETE" och att den är korrekt URL blir träffad, vilket i vårt fall borde vara http://localhost:52645/TutorialService.svc/TutorialSe till att ID:t som används för att ta bort en sträng i listan skickas via URL som en parameter. I vårt REST-exempel skickar vi 1, så detta kommer att ta bort 2:an^nd elementet i vår samling, som är ”Köer”.

Slutligen klickar du bara på knappen Utför i FiddlerDetta skickar en begäran till webbtjänsten om att RADERA data-"köerna" från vår webbtjänst.

Nu, när vi bläddrar till handledningen URL För att visa alla strängar i vår handledningslista kommer du att märka att värdet för "Köer" inte längre finns.

Detta visar att DELETE-begäran till webbtjänsten har körts. Elementet vid indexnummer 1 i vår lista över handledningssträngar har tagits bort.

Bästa praxis för RESTful API

Att bygga ett REST API som fungerar är bara det första steget; att bygga ett som skalar och förblir underhållbart kräver disciplin. Metoderna nedan hjälper till att hålla dina slutpunkter förutsägbara, säkra och enkla för andra utvecklare och AI-agenter att använda.

• Använd substantiv, inte verb, i URLs. Ändpunkter som t.ex. /anställda/1 är tydligare än /getEmployee?id=1, eftersom HTTP-verbet redan beskriver handlingen.
• Returnera meningsfulla statuskoder. Skicka 200 för lyckad begäran, 201 för en skapad resurs, 400 för en felaktig begäran, 401 för obehörig åtkomst, 404 för en saknad resurs och 500 för serverfel.
• Versionera ditt API. Lägga till ett versionssegment som t.ex. /v1/ i sökvägen kan du utveckla tjänsten utan att förstöra befintliga kunder.
• Säkra varje slutpunkt. Använd HTTPS, tillsammans med API-nycklar eller OAuth 2.0-tokens, och validera all inkommande inmatning.
• Stöd för paginering och filtrering. Att returnera stora samlingar i sidor håller svaren snabba och minskar serverbelastningen.

Att följa dessa konventioner gör din RESTful-webbtjänst intuitiv att integrera, oavsett om konsumenten är en mobilapp, ett partnersystem eller ett automatiserat AI-arbetsflöde.

Vanliga frågor