Vodič za RESTful web usluge: Primjer REST API-ja

Zašto koristiti Restful Web Services?

Prije istraživanja tehničkih detalja, korisno je razumjeti zašto je REST postao toliko popularan. RESTful web servisi postali su istaknuti iz sljedećih razloga:

1. Heterogeni jezici i okruženja – To je jedan od temeljnih razloga, isti kao što smo vidjeli za SOAP kao dobro.

• Omogućuje web aplikacijama izgrađenim na različitim programskim jezicima da međusobno komuniciraju.
• Uz pomoć Restful usluga, ove web aplikacije mogu se nalaziti u različitim okruženjima; neke bi mogle biti na Windows, a ostali bi mogli biti na Linuxu.

Na kraju, bez obzira na okruženje, rezultat bi uvijek trebao biti isti: aplikacije bi trebale moći međusobno komunicirati. Restful web servisi nude ovu fleksibilnost aplikacijama izgrađenim na raznim programskim jezicima i platformama.

Donja slika prikazuje primjer web aplikacije koja mora komunicirati s drugim aplikacijama poput Facebooka, Twittera i Google.

Ako bi klijentska aplikacija morala raditi sa stranicama poput Facebooka i Twittera, programeri bi obično morali znati na kojem su jeziku i platformi te stranice izgrađene. Na temelju toga mogli bi napisati kod za sučelje, ali održavanje ovog pristupa moglo bi se pokazati kao noćna mora.

Umjesto toga, Facebook, Twitter i Google izložiti njihovu funkcionalnost u obliku Restful web servisa. To omogućuje bilo kojoj klijentskoj aplikaciji pozivanje ovih web servisa putem REST-a, bez obzira na temeljnu tehnologiju.

2. Događaj uređaja – U današnje vrijeme treba raditi na svemu Kontakt broj uređaje, bilo da se radi o mobitelu, prijenosnom računalu ili čak automobilskom sustavu.

Zamislite koliko je truda potrebno za kodiranje aplikacija na tim uređajima kako bi komunicirale s normalnim web aplikacijama. Restful API-ji ponovno olakšavaju ovaj posao jer, kao što je spomenuto u prvoj točki, zapravo ne morate znati temeljni sloj uređaja.

3. Događaj Oblaka – Sve se seli u oblak. Aplikacije se polako sele na sustave temeljene na oblaku kao što su Azure or Amazon. Azure i Amazon pružaju mnoge API-je temeljene na Restful arhitekturi. Stoga se aplikacije sada moraju razvijati na način da budu kompatibilne s oblakom. Budući da sve arhitekture temeljene na oblaku rade na REST principu, ima smisla da se web servisi programiraju na REST arhitekturi kako bi se što bolje iskoristili cloud servisi.

RESTful ključni elementi

REST web servisi su od svog nastanka prošli dug put. Godine 2002. Web konzorcij je objavio definiciju WSDL i SOAP web servisa. To je formiralo standard za način implementacije web servisa.

Godine 2004. web konzorcij je također objavio definiciju dodatnog standarda pod nazivom RESTful. Tijekom proteklih nekoliko godina ovaj je standard postao prilično popularan i sada ga koriste mnoge od najpopularnijih web stranica diljem svijeta, uključujući Facebook i Twitter.

REST je način pristupa resursima koji se nalaze u određenom okruženju. Na primjer, možete imati poslužitelj koji hostira važne dokumente, slike ili videozapise. Sve su to primjeri resursa. Ako klijent, poput web preglednika, treba bilo koji od ovih resursa, mora poslati zahtjev poslužitelju. REST usluge definiraju standardni način na koji se tim resursima može pristupiti.

Ključni elementi RESTful implementacije su sljedeći:

1. Resursi – Prvi ključni element je sam resurs. Pretpostavimo da web aplikacija na poslužitelju ima zapise o nekoliko zaposlenika. Pretpostavimo da URL web aplikacije je https://demo.guru99.comSada, kako bi se pristupilo resursu evidencije zaposlenika putem REST usluga, može se izdati naredba https://demo.guru99.com/employee/1Ova naredba upućuje web poslužitelj da dostavi podatke o zaposleniku čiji je broj zaposlenika 1.
2. Glagoli zahtjeva – Ovo opisuje što želite učiniti s resursom. Preglednik izdaje GET glagol kako bi uputio krajnju točku da želi dobiti podatke. Međutim, dostupni su mnogi drugi glagoli, uključujući POST, PUT i DELETE. Dakle, u slučaju primjera https://demo.guru99.com/employee/1, web preglednik zapravo izdaje GET glagol jer želi dobiti detalje o zaposleničkom zapisu.
3. Zatraži zaglavlja – To su dodatne upute poslane sa zahtjevom. One mogu definirati vrstu potrebnog odgovora ili detalje autorizacije.
4. Tijelo zahtjeva – Ovo su podaci poslani sa zahtjevom. Podaci se obično šalju u tijelu zahtjeva kada se POST zahtjev uputi REST web servisu. U POST pozivu klijent govori REST web servisu da želi dodati resurs poslužitelju. Dakle, tijelo zahtjeva bi imalo detalje o resursu koji treba dodati.
5. Tijelo odgovora – Ovo je glavni dio odgovora. Dakle, u našem primjeru RESTful API-ja, ako bismo upitali web poslužitelj putem zahtjeva https://demo.guru99.com/employee/1, web poslužitelj bi mogao vratiti XML dokument sa svim podacima o zaposleniku u tijelu odgovora.
6. Kodovi statusa odgovora – Ovo su opći kodovi koji se vraćaju uz odgovor web poslužitelja. Primjer je kod 200, koji se obično vraća kada nema pogreške prilikom vraćanja odgovora klijentu.

Umirujuće metode

Donji dijagram prikazuje većinu glagola (POST, GET, PUT i DELETE) i REST API primjer što bi oni značili.

Pretpostavimo da imamo definiran RESTful web servis na lokaciji https://demo.guru99.com/employeeKada klijent uputi bilo koji zahtjev ovoj web usluzi, može navesti bilo koji od uobičajenih HTTP glagola GET, POST, DELETE i PUT. U nastavku je prikazano što bi se dogodilo ako bi klijent poslao odgovarajuće glagole.

1. POST – Ovo bi se koristilo za stvaranje novog zaposlenika pomoću RESTful web servisa.
2. GET – Ovo bi se koristilo za dobivanje popisa svih zaposlenika koji koriste RESTful web uslugu.
3. PUT – Ovo bi se koristilo za ažuriranje svih zaposlenika koji koriste RESTful web uslugu.
4. DELETE – Ovo bi se koristilo za brisanje svih zaposlenika koji koriste RESTful uslugu.

Sada pogledajmo iz perspektive samo jednog zapisa. Recimo da postoji zapis zaposlenika s brojem zaposlenika 1. Sljedeće radnje imale bi svoja odgovarajuća značenja.

1. POST – Ovo ne bi bilo primjenjivo jer dohvaćamo podatke zaposlenika 1, koji su već kreirani.
2. GET – Ovo bi se koristilo za dobivanje podataka o zaposleniku s brojem zaposlenika 1 pomoću RESTful web servisa.
3. PUT – Ovo bi se koristilo za ažuriranje podataka zaposlenika s brojem zaposlenika 1 pomoću RESTful web servisa.
4. DELETE – Ovo se koristi za brisanje podataka zaposlenika s brojem zaposlenika 1.

Miran Architektura

Aplikacija ili arhitektura koja se smatra RESTful ili REST-stilom ima sljedeće karakteristike.

1. Stanje i funkcionalnost dijele se na distribuirane resurse – To znači da bi svaki resurs trebao biti dostupan putem uobičajenih HTTP naredbi GET, POST, PUT ili DELETE. Dakle, ako netko želi dobiti datoteku s poslužitelja, trebao bi moći izdati GET zahtjev i dobiti datoteku. Ako žele staviti datoteku na poslužitelj, trebali bi moći izdati POST ili PUT zahtjev. Konačno, ako žele izbrisati datoteku s poslužitelja, mogu izdati DELETE zahtjev.

2. Arhitektura je klijent/poslužitelj, bez stanja, slojevita i podržava predmemoriranje.

• Klijent-poslužitelj je tipična arhitektura gdje poslužitelj može biti web poslužitelj koji hostira aplikaciju, a klijent može biti jednostavan kao web preglednik.
• Bez stanja znači da se stanje aplikacije ne održava u REST-u. Na primjer, ako izbrišete resurs s poslužitelja pomoću naredbe DELETE, ne možete očekivati ​​da će se informacije o brisanju proslijediti sljedećem zahtjevu.

Kako biste osigurali brisanje resursa, morali biste izdati GET zahtjev. GET zahtjev bi se prvo koristio za dohvaćanje svih resursa na poslužitelju, nakon čega bi trebalo provjeriti je li resurs doista izbrisan.

RESTFul principi i ograničenja

REST arhitektura temelji se na nekoliko karakteristika koje su detaljnije opisane u nastavku. Svaka RESTful web usluga mora biti u skladu s dolje navedenim karakteristikama da bi se mogla nazvati RESTful. Ove karakteristike poznate su i kao principi dizajna kojih se treba pridržavati pri radu s RESTful uslugama.

1. RESTFul klijent-poslužitelj

   

Ovo je najosnovniji zahtjev REST arhitekture. To znači da će poslužitelj imati RESTful web uslugu koja pruža potrebnu funkcionalnost klijentu. Klijent šalje zahtjev web usluzi na poslužitelju. Poslužitelj zatim ili odbija zahtjev ili ga udovoljava i pruža odgovarajući odgovor klijentu.

2. bez države

Koncept bezdržavnosti znači da je na klijentu osigurati da se poslužitelju dostave sve potrebne informacije. To je potrebno kako bi poslužitelj mogao ispravno obraditi odgovor. Poslužitelj ne bi trebao čuvati nikakve informacije između zahtjeva klijenta. To je vrlo jednostavan, neovisan niz pitanja i odgovora. Klijent postavlja pitanje, a poslužitelj na njega odgovara na odgovarajući način. Kada klijent postavi drugo pitanje, poslužitelj se neće sjetiti prethodnog scenarija pitanja i odgovora i morat će samostalno odgovoriti na novo pitanje.

3. Cache

Koncept predmemorije pomaže s problemom apatridije opisanim u posljednjoj točki. Budući da je svaki zahtjev poslužitelj-klijent neovisan po prirodi, klijent ponekad može ponovno zatražiti od poslužitelja isti zahtjev, iako ga je već u prošlosti zatražio. Ovaj zahtjev će ići poslužitelju, a poslužitelj će dati odgovor, što povećava promet na mreži. Predmemorija je koncept implementiran na klijentu za pohranjivanje zahtjeva koji su već poslani poslužitelju. Dakle, ako isti zahtjev da klijent, umjesto da ide poslužitelju, on će otići u predmemoriju i dobiti potrebne informacije. To štedi količinu mrežnog prometa između klijenta i poslužitelja.

4. Slojeviti sustav

Koncept slojevitog sustava je da se bilo koji dodatni sloj, poput sloja middlewarea, može umetnuti između klijenta i stvarnog poslužitelja koji hostira RESTFul web uslugu. (Sloj middlewarea je mjesto gdje se stvara sva poslovna logika. To može biti dodatna usluga s kojom klijent komunicira prije nego što uputi poziv web usluzi.) Ali uvođenje ovog sloja mora biti transparentno kako ne bi ometalo interakciju između klijenta i poslužitelja.

5. Sučelje/Uniform Contract

Ovo je temeljna tehnika kako bi RESTful web servisi trebali funkcionirati. RESTful u osnovi radi na HTTP web sloju i koristi ključne glagole u nastavku za rad s resursima na poslužitelju.

• POST – Za stvaranje resursa na poslužitelju.
• GET – Za dohvaćanje resursa s poslužitelja.
• PUT – Za promjenu stanja resursa ili njegovo ažuriranje.
• IZBRIŠI – Za uklanjanje ili brisanje resursa s poslužitelja.

REST vs SOAP: Ključne razlike

Programeri često uspoređuju REST i SOAP prilikom dizajniranja web servisa. Oba omogućuju komunikaciju distribuiranih aplikacija, ali se oštro razlikuju u filozofiji. REST je arhitektonski stil koji koristi jednostavne HTTP glagole i lagane formate poput JSON-a, dok SOAP je strogi protokol koji se oslanja na XML omotnice i formalni kontract. Tablica u nastavku sažima najvažnije razlike.

U praksi, REST je zadani izbor za javne web i mobilne API-je jer je brži i jednostavniji za korištenje, dok SOAP ostaje koristan za poslovne sustave koji zahtijevaju ugrađenu sigurnost i formalnu kontrolu.tracts.

Stvorite svoju prvu Restful web uslugu u ASP.NET-u

Sada ćemo u ovom REST API tutorialu naučiti kako stvoriti Restful web servis u ASP.NET-u.

Web servisi mogu se kreirati u raznim jezicima, a mnoga integrirana razvojna okruženja mogu se koristiti za kreiranje REST servisa.

U ovom primjeru RESTful API-ja, izradit ćemo našu REST aplikaciju u .NET-u pomoću Visual Studija. Imat ćemo Restful web uslugu koja će raditi na skupu podataka u nastavku.

Skup podataka u nastavku predstavlja REST API primjer tvrtke koja objavljuje tutorijale koje ima na temelju Tutorialid-a.

U našem primjeru tutorijala za REST API, implementirat ćemo Restful glagole u nastavku.

1. PREUZMI Vodič – Kada klijent pozove ovaj Restful API, dobit će cijeli skup tutorijala dostupnih s web servisa.
2. GET Tutorial/Tutorialid – Kada klijent pozove ovaj Restful API, dobit će naziv tutoriala na temelju Tutorialid-a koji je poslao klijent.
3. POST Tutorial/Tutorialname – Kada klijent pozove ovaj Restful API, klijent će poslati zahtjev za umetanje naziva tutorijala. Web servis će zatim dodati poslani naziv tutorijala u kolekciju.
4. DELETE Tutorial/Tutorialid – Kada klijent pozove ovaj Restful API, klijent će poslati zahtjev za brisanje naziva tutorijala na temelju ID-a tutorijala. Web servis će zatim izbrisati poslani naziv tutorijala iz kolekcije.

Slijedimo dolje navedene korake kako bismo stvorili našu prvu RESTful web uslugu koja provodi gore navedenu implementaciju.

Kako stvoriti svoju prvu umirujuću web uslugu

Korak 1) Izradite novi projekt.
Prvi korak je stvaranje praznog Asp.Net web aplikacija. Iz Visual Studija 2013 kliknite na opciju izbornika Datoteka->Novi projekt.

Nakon što kliknete na opciju Novi projekt, Visual Studio će vam dati još jedan dijaloški okvir za odabir vrste projekta i unos potrebnih podataka. To je objašnjeno u sljedećem koraku.

Korak 2) Unesite naziv i lokaciju projekta.

1. Uvjerite se da prvo odaberete C# web predložak ASP.NET web aplikacije. Projekt mora biti ovog tipa kako bi se stvorio projekt web servisa. Odabirom ove opcije, Visual Studio će izvršiti potrebne korake za dodavanje potrebnih datoteka za bilo koju web aplikaciju.
2. Dajte naziv svom projektu, što je u našem slučaju „Webservice.REST“.
3. Zatim provjerite jeste li naveli lokaciju gdje će se pohraniti datoteke projekta.

Nakon što završite, vidjet ćete stvorenu datoteku projekta u vašem istraživaču rješenja u Visual Studiju 2013.

Korak 3) Stvorite datoteku web usluge.
Sljedeći korak je stvaranje datoteke web servisa koja će sadržavati RESTful web servis.

1. Prvo, desnom tipkom miša kliknite datoteku projekta kao što je prikazano dolje.

2. U ovom koraku
   1. Desnom tipkom miša kliknite datoteku projekta.
   2. Odaberite opciju "Dodaj->Nova stavka".

U dijaloškom okviru koji se pojavi, potrebno je izvršiti sljedeće.

1. Odaberite opciju WCF usluga (omogućeno za Ajax). Odabirom datoteke ove vrste Visual Studio dodaje osnovni kod koji vam pomaže u stvaranju RESTful web usluge. WCF je kratica za Windows komunikacija FoundationWCF je biblioteka za aplikacije različitih platformi (ili iste platforme) za komunikaciju putem različitih protokola kao što su TCP, HTTP i HTTPS. Ajax je asinkroni. JavaScript i XML. AJAX omogućuje asinkrono ažuriranje web stranica razmjenom malih količina podataka s poslužiteljem iza scene.
2. Zatim, dajte naziv servisu, što je u našem slučaju TutorialService.
3. Na kraju kliknite gumb Dodaj kako biste uslugu dodali u rješenje.

Korak 4) Napravite konfiguraciju.
Sljedeći korak je napraviti promjenu konfiguracije kako bi se omogućio rad ovog projekta s RESTful web servisima. To zahtijeva promjenu datoteke pod nazivom Web.configOva se datoteka pojavljuje u istom prozoru kao i datoteka projekta web-servisa. Datoteka Web.config sadrži sve konfiguracije koje omogućuju ispravno funkcioniranje web-aplikacije. Promjena koja se vrši omogućuje aplikaciji slanje i primanje podataka kao čista RESTful web-usluga.

1. Kliknite na datoteku Web.config da biste otvorili kod.

2. Pronađite liniju .

3. Promijeni liniju u .

Korak 5) Dodajte naš kod za implementaciju.
Sljedeći korak je dodavanje našeg koda za implementaciju. Sav donji kod mora biti napisan u datoteci TutorialService.svc.

1. Prvi dio je dodati kod koji predstavlja naše podatke, koji će se koristiti u našem programu. Dakle, imat ćemo popis string varijabli s vrijednostima "Nizovi", "Redovi čekanja" i "Stogovi". To će predstavljati nazive tutorijala dostupnih putem naše web usluge hostinga.

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

Korak 6) Definirajte kod za našu GET metodu.
Zatim ćemo definirati kod za našu GET metodu. Ovaj kod će se također nalaziti u istoj datoteci TutorialService.svc. Ovaj kod će se pokrenuti svaki put kada pozovemo uslugu iz našeg preglednika.

Donja metoda će se koristiti za ispunjavanje dolje navedenog scenarija.

• Ako korisnik želi popis svih dostupnih tutorijala, tada bi trebalo napisati donji kod kako bi se to postiglo.

[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 Obrazloženje:-

1. Prvi redak koda je najvažniji. Koristi se za definiranje kako možemo pozvati ovu metodu putem URLDakle, ako je poveznica na našu web uslugu http://localhost:52645/TutorialService.svc i dodajemo '/Tutorial' u URL, kao u http://localhost:52645/TutorialService.svc/Tutorial, gornji kod će biti pozvan. Atribut 'WebGet' je parametar koji omogućuje da ova metoda bude RESTful metoda tako da se može pozvati putem GET glagola.
2. Ovaj dio koda koristi se za prolazak kroz naš popis nizova u 'lst' varijabli i vraćanje svih njih pozivnom programu.

Korak 7) Vrati izlaz.
Donji kod osigurava da ako se uputi GET poziv servisu Tutorial s ID-om Tutorial, vratit će se odgovarajući naziv vodiča na temelju ID-a vodiča.

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

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

Code Obrazloženje:-

1. Prvi redak koda je najvažniji. Definira kako možemo pozvati ovu metodu putem URLDakle, ako je poveznica na našu web uslugu http://localhost:52645/TutorialService.svc i dodajemo '/Tutorial/{Tutorialid}' u URL, mogli bismo pozvati web servis kao http://localhost:52645/TutorialService.svc/Tutorial/1, na primjer. Web servis bi tada vratio naziv tutorijala koji je imao ID tutorijala 1.
2. Ovaj dio koda koristi se za vraćanje naziva tutorijala kojem je ID tutorijala proslijeđen web metodi.

• Prema zadanim postavkama, ono što treba zapamtiti jest da sve što se prosljeđuje URL u pregledniku je niz znakova.
• Ali morate zapamtiti da indeks naše liste mora biti cijeli broj, pa dodajemo potreban kod za prvo pretvaranje Tutorialid-a u cijeli broj.
• Zatim ga koristimo za pristup indeksnoj poziciji na našoj listi i vraćamo vrijednost pozivnom programu u skladu s tim.

Korak 8) Napišite kod za POST metodu.
Sljedeći korak je pisanje koda za našu POST metodu. Ova metoda će se pozivati ​​kad god želimo dodati niz vrijednosti na naš popis tutorijala putem POST metode. Na primjer, ako želite dodati naziv tutorijala "Testiranje softvera", tada biste morali koristiti POST metodu.

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

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

Code Obrazloženje:-

1. Prvi redak je atribut 'WebInvoke', koji je pridružen našoj metodi. To omogućuje pozivanje metode putem POST poziva. Atributi RequestFormat i ResponseFormat moraju se spomenuti kao JSON, budući da prilikom slanja vrijednosti na RESTFul web servis, vrijednosti moraju biti u ovom formatu.
2. Drugi redak koda koristi se za dodavanje vrijednosti niza znakova proslijeđenog putem POST poziva našem postojećem popisu nizova znakova u tutorialu.

Korak 9) Dodajte metodu za obradu operacije DELETE.
Konačno, dodat ćemo našu metodu za obradu operacije DELETE. Ova metoda će se pozivati ​​kad god želimo izbrisati postojeću vrijednost niza s našeg popisa tutorijala putem metode DELETE.

[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 Obrazloženje:-

1. Prvi redak je atribut 'WebInvoke', koji je pridružen našoj metodi. To omogućuje pozivanje metode putem poziva DELETE. Atributi RequestFormat i ResponseFormat moraju se spomenuti kao JSON, budući da vrijednosti moraju biti u tom formatu. Imajte na umu da je parametar Method postavljen na "DELETE". To znači da će se ova metoda pozvati kad god izdamo glagol DELETE.
2. Drugi redak koda koristi se za preuzimanje Tutorialid-a poslanog putem DELETE poziva i naknadnog brisanja tog ID-a s našeg popisa. ( Int32 Funkcija u kodu se koristi za pretvaranje ID-a tutorijala iz niza znakova u cijeli broj.)

Pokretanje vaše prve web usluge Restful

Sada kada smo u gornjem odjeljku kreirali cijelu web uslugu, pogledajmo kako možemo pokrenuti uslugu Tutorial tako da se može pozvati s bilo kojeg klijenta.

Za pokretanje web servisa, slijedite dolje navedene korake.

Korak 1) Desnom tipkom miša kliknite datoteku projekta – Webservice.REST.

Korak 2) Odaberite opciju izbornika 'Postavi kao projekt pri pokretanju'. To će osigurati da se ovaj projekt pokrene kada Visual Studio pokrene cijelo rješenje.

Korak 3) Sljedeći korak je pokretanje samog projekta. Ovisno o zadanom pregledniku instaliranom na sustavu, odgovarajući naziv preglednika pojavit će se pored gumba za pokretanje u Visual Studiju. U našem slučaju imamo Google Chrome pojavljivanje. Samo kliknite na ovaj gumb.

Izlaz:-

Kada se projekt pokrene, možete pregledati odjeljak TutorialService.svc/Tutorial i dobit ćete rezultat prikazan u nastavku.

U gornjem izlazu,

• Možete vidjeti da preglednik poziva glagol 'GET' i izvršava metodu 'GetAllTutorial' u web servisu. Ovaj modul se koristi za prikaz svih tutorijala koje pruža naš web servis.

Testiranje vaše prve web usluge Restful

U gornjem odjeljku već smo vidjeli kako koristiti preglednik za izvršavanje glagola 'GET' i pozivanje 'GetAllTutorial'.

1. Upotrijebimo sada preglednik za izvođenje sljedećeg scenarija upotrebe.

GET Tutorial/Tutorialid – Kada klijent pozove ovaj Restful API, dobit će naziv tutoriala na temelju Tutorialid-a koji je poslao klijent.

U pregledniku dodajte niz /1 nakon riječi Tutorial u URLAko pritisnete tipku Enter, dobit ćete donji izlaz.

Sada ćete vidjeti izlaz "Redova redova", što odgovara broju 1 na našem popisu stringova tutoriala. To znači da se metoda 'GetTutorialbyID' sada poziva iz naše web usluge. Također pokazuje da se vrijednost 1 uspješno prenosi putem preglednika našoj web usluzi i našoj metodi, te zato dobivamo ispravnu odgovarajuću vrijednost "Redova redova" u pregledniku.

2. Zatim, konzumirajmo našu web uslugu izvršavanjem scenarija u nastavku. Za to trebate instalirati alat pod nazivom Fiddler, što je alat koji se može besplatno preuzeti.

POST Vodič/NazivVodiča – Kada klijent pozove ovaj Restful API, klijent će poslati zahtjev za umetanje nazivaVodiča. Web servis će zatim dodati poslani naziv vodiča u kolekciju.

Pokreni Fiddler alat i izvršite dolje navedene korake.

1. Idite na odjeljak za sastavljanje. Koristi se za izradu zahtjeva koji se mogu poslati bilo kojoj web aplikaciji.
2. Provjerite je li vrsta zahtjeva "POST" i je li ispravno URL biva pogođen, što bi u našem slučaju trebalo biti http://localhost:52645/TutorialService.svc/Tutorial.
3. Provjerite je li Content-Type označen kao application/json. Imajte na umu da naša POST metoda zahtjeva u našoj web usluzi prihvaća samo podatke u JSON stilu, stoga moramo osigurati da je to navedeno kada šaljemo zahtjev našoj aplikaciji.
4. Konačno, moramo unijeti naše podatke. Imajte na umu da naša metoda za POST prihvaća parametar pod nazivom 'str'. Dakle, ovdje navodimo da želimo dodati vrijednost pod nazivom "Stabla" našoj kolekciji naziva tutorijala i osigurati da je označena s nazivom varijable 'str'.

Na kraju, samo kliknite gumb Izvrši u FiddlerOvim će se poslati zahtjev web servisu za POST podatke „Drveće“ našem web servisu.

Sada, kada pregledamo Vodič URL Da biste prikazali sve nizove znakova na našem popisu tutorijala, vidjet ćete da je prisutna i vrijednost "Trees". To pokazuje da je POST zahtjev web servisu uspješno izvršen i da je uspješno dodan na naš popis tutorijala.

3. Zatim, konzumirajmo našu web uslugu izvršavanjem scenarija u nastavku. Za to također moramo koristiti Fiddler alat.

IZBRIŠI Vodič/ID Vodiča – Kada klijent pozove ovaj Restful API, klijent će poslati zahtjev za brisanje naziva Vodiča na temelju ID-a Vodiča. Web servis će zatim izbrisati poslani naziv vodiča iz kolekcije.

Pokreni Fiddler alat i izvršite dolje navedene korake.

1. Idite na odjeljak za sastavljanje. Koristi se za izradu zahtjeva koji se mogu poslati bilo kojoj web aplikaciji.
2. Provjerite je li vrsta zahtjeva "IZBRIŠI" i je li ispravno URL biva pogođen, što bi u našem slučaju trebalo biti http://localhost:52645/TutorialService.svc/TutorialOsigurajte da se ID koji se koristi za brisanje niza na popisu šalje putem URL kao parametar. U našem REST primjeru šaljemo 1, pa će se time izbrisati 2^nd element u našoj kolekciji, a to je „Redovi čekanja“.

Na kraju, samo kliknite gumb Izvrši u FiddlerOvim će se web servisu poslati zahtjev za IZBRISAVANJE podataka "Redova čekanja" s našeg web servisa.

Sada, kada pregledamo Vodič URL Da biste prikazali sve nizove znakova na našem popisu u tutorijalu, primijetit ćete da vrijednost "Redovi čekanja" više nije prisutna.

Ovo pokazuje da je zahtjev DELETE upućen web servisu uspješno izvršen. Element na indeksnom broju 1 u našem popisu stringova tutoriala uspješno je izbrisan.

Najbolje prakse RESTful API-ja

Izgradnja REST API-ja koji funkcionira samo je prvi korak; izgradnja onog koji se skalira i ostaje održiv zahtijeva disciplinu. Prakse u nastavku pomažu u održavanju predvidljivosti, sigurnosti i jednostavnosti korištenja krajnjih točaka za druge razvojne programere i AI agente.

• Koristite imenice, a ne glagole, u URLs. Krajnje točke kao što su /zaposlenici/1 jasnije su od /getEmployee?id=1, jer HTTP glagol već opisuje radnju.
• Vrati značajne statusne kodove. Pošalji 200 za uspjeh, 201 za kreirani resurs, 400 za loš zahtjev, 401 za neovlašteni pristup, 404 za nedostajući resurs i 500 za pogreške poslužitelja.
• Verzirajte svoj API. Dodavanje segmenta verzije kao što je /v1/ u putanji vam omogućuje razvoj usluge bez prekida rada postojećih klijenata.
• Osigurajte svaku krajnju točku. Koristite HTTPS, zajedno s API ključevima ili OAuth 2.0 tokenima i provjerite sve dolazne unose.
• Podrška za paginaciju i filtriranje. Vraćanje velikih kolekcija na stranicama održava odgovore brzima i smanjuje opterećenje poslužitelja.

Slijeđenje ovih konvencija čini vašu RESTful web uslugu intuitivnom za integraciju, bez obzira je li potrošač mobilna aplikacija, partnerski sustav ili automatizirani AI tijek rada.

Pitanja i odgovori