RESTful Web Services oktatóanyag REST API példával

Tartalomjegyzék:

Anonim

Mi az a nyugodt webszolgáltatás?

A Restful Web Services egy könnyű, karbantartható és méretezhető szolgáltatás, amely a REST architektúrára épül. Nyugodt webszolgáltatás, tegye ki az API-t az alkalmazásból biztonságos, egységes és hontalan módon a hívó kliens számára. A hívó kliens előre meghatározott műveleteket hajthat végre a Restful szolgáltatás használatával. A REST alapul szolgáló protokollja a HTTP. A REST jelentése REpresentational State Transfer.

Ebben a REST API oktatóanyagban megtanulja-

  • Pihentető kulcselemek
  • Nyugodt módszerek
  • Miért pihentető
  • Nyugodt építészet
  • RestFul alapelvek és korlátozások
  • Készítse el első nyugodt webszolgáltatását az ASP.NET-ben
  • Az első nyugodt webszolgáltatás futtatása
  • Az első nyugodt webszolgáltatás tesztelése

Pihentető kulcselemek

A REST webszolgáltatások megalakulása óta valóban hosszú utat tettek meg. 2002-ben a webkonzorcium kiadta a WSDL és a SOAP webszolgáltatások definícióját. Ez alkotta a webszolgáltatások megvalósításának színvonalát.

2004-ben a webkonzorcium kiadta a RESTful nevű kiegészítő szabvány meghatározását is. Az elmúlt néhány évben ez a szabvány meglehetősen népszerűvé vált. És a világ számos népszerű webhelye használja, köztük a Facebook és a Twitter.

A REST az erőforrásokhoz való hozzáférés módja, amelyek egy adott környezetben rejlenek. Például lehet egy szervere, amely fontos dokumentumokat, képeket vagy videókat tárolhat. Mindezek példák az erőforrásokra. Ha egy kliensnek mondjuk egy webböngészőnek szüksége van ezekre az erőforrásokra, akkor kérést kell küldenie a kiszolgálónak, hogy hozzáférjen ezekhez az erőforrásokhoz. Most a REST szolgáltatások meghatározzák az erőforrásokhoz való hozzáférés módját.

A RESTful megvalósítás fő elemei a következők:

  1. Erőforrások - Az első kulcselem maga az erőforrás. Tegyük fel, hogy egy szerveren található webalkalmazás több alkalmazott nyilvántartásával rendelkezik. Tegyük fel, hogy a webalkalmazás URL-je a http://demo.guru99.com . Annak érdekében, hogy a REST szolgáltatásokon keresztül hozzáférhessen az alkalmazottak nyilvántartási erőforrásaihoz, kiadhatja a következő parancsot: http://demo.guru99.com/employee/1 - Ez a parancs megadja a webszervernek, hogy adja meg annak az alkalmazottnak az adatait, akinek az alkalmazottjának száma 1.

  2. Igénylő igék - Ezek leírják, hogy mit szeretne kezdeni az erőforrással. A böngésző kiad egy GET igét, hogy utasítsa a végpontot, amely adatokat akar kapni. Számos más igék állnak rendelkezésre, például POST, PUT és DELETE. Tehát a http://demo.guru99.com/employee/1 példa esetében a webböngésző valójában kiad egy GET igét, mert meg akarja szerezni az alkalmazotti rekord részleteit.

  3. Kérés fejlécek - Ezek a kéréssel együtt küldött további utasítások. Ezek meghatározhatják a szükséges válasz típusát vagy az engedélyezés részleteit.

  4. Request Body - Az adatokat a kéréssel együtt küldjük el. Az adatokat rendszerint a kérelem küldi, amikor POST kérést küldnek a REST webszolgáltatásoknak. A POST hívás során az ügyfél valóban elmondja a REST webszolgáltatásoknak, hogy erőforrást szeretne hozzáadni a kiszolgálóhoz. Ennélfogva a kérelem testületének rendelkeznie kell a szerverhez hozzáadni szükséges erőforrás részleteivel.

  5. Válasz Test - Ez a válasz fő teste. Tehát a RESTful API példánkban, ha a webkiszolgálót a http://demo.guru99.com/employee/1 kérésen keresztül kérdeznénk , akkor a webkiszolgáló XML dokumentumot adhat vissza, amelyben a válasz minden részletét az alkalmazott tartalmazza. Test.

  6. Válasz állapotkódok - Ezek az általános kódok, amelyeket a webkiszolgáló válaszaival együtt adnak vissza. Példaként említhetjük a 200 kódot, amelyet általában akkor adunk vissza, ha nincs hiba a válasz visszaadásakor az ügyfélnek.

Nyugodt módszerek

Az alábbi ábra többnyire az összes igét (POST, GET, PUT és DELETE) és egy REST API példát mutatja be, hogy mit jelentenek.

Tegyük fel, hogy RESTful webszolgáltatás van megadva a helyszínen. http://demo.guru99.com/employee . Amikor az ügyfél bármilyen kérést intéz ehhez a webszolgáltatáshoz, megadhatja a GET, POST, DELETE és PUT szokásos HTTP igéit. Az alábbiakban bemutatjuk, mi történne, ha a megfelelő igéket az ügyfél küldené.

  1. POST - Ezt a RESTful webszolgáltatás használatával új munkatárs létrehozására használják
  2. GET - Ezzel fel lehet szerezni a RESTful webszolgáltatást használó összes alkalmazott listáját
  3. PUT - Ez a RESTful webszolgáltatást használó összes alkalmazott frissítésére szolgál
  4. TÖRLÉS - Ez a RESTful szolgáltatásokat használó összes alkalmazott törlésére szolgál

Vessünk egy pillantást egyetlen lemez perspektívájából. Tegyük fel, hogy volt egy alkalmazotti nyilvántartás, amelynek alkalmazott száma 1 volt.

A következő műveleteknek megvan a maguk jelentése.

  1. POST - Ez nem lenne alkalmazható, mivel lekérjük az 1. alkalmazott már létrehozott adatait.
  2. GET - Ezt arra használják, hogy a RESTful webszolgáltatás használatával megkapják az 1. számú alkalmazottal rendelkező munkavállaló adatait
  3. PUT - Ezt a RESTful webszolgáltatás használatával frissítenék az 1-es számú Munkavállaló munkatársaival
  4. TÖRLÉS - Ezzel az 1-es alkalmazottal rendelkező alkalmazott adatait törölhetjük

Miért pihentető

A nyugodt leginkább a következő okok miatt vált népszerűvé:

  1. Heterogén nyelvek és környezetek - Ez az egyik alapvető ok, amely megegyezik a SOAP esetében is.
  • Lehetővé teszi a különféle programozási nyelvekre épülő webalkalmazások kommunikációját egymással
  • A Restful szolgáltatások segítségével ezek a webalkalmazások különböző környezetekben tartózkodhatnak, egyesek lehetnek Windows rendszeren, mások pedig Linuxon.

De végül, függetlenül attól, hogy milyen a környezet, a végeredménynek mindig ugyanannak kell lennie, hogy képesek legyenek egymással beszélgetni. A pihentető webszolgáltatások ezt a rugalmasságot kínálják a különféle programozási nyelvekre és platformokra épülő alkalmazások számára, hogy egymással beszélhessenek.

Az alábbi kép egy példát mutat be egy webalkalmazásra, amelynek követelménye, hogy beszéljen más alkalmazásokkal, mint például a Facebook, a Twitter és a Google.

Most, ha egy ügyfélalkalmazásnak olyan webhelyekkel kellene működnie, mint a Facebook, a Twitter stb., Valószínűleg tudnia kell, hogy a Facebook, a Google és a Twitter milyen nyelven épül fel, és azt is, hogy milyen platformon építenek.

Ez alapján megírhatjuk a webes alkalmazásunk interfész kódját, de ez rémálommá válhat.

A Facebook, a Twitter és a Google a Restful webszolgáltatások formájában tárja fel funkcionalitását. Ez lehetővé teszi, hogy bármely ügyfélalkalmazás felhívhassa ezeket a webszolgáltatásokat a REST-en keresztül.

  1. Az Eszközök eseménye - Manapság mindennek működnie kell a mobileszközökön, legyen szó akár mobileszközről, noteszgépekről vagy akár autórendszerekről.

    El tudja képzelni, mennyi erőfeszítést kell kipróbálni az alkalmazások kódolására ezeken az eszközökön a normál webalkalmazásokkal való beszélgetéshez? Ismét a Restful API-k egyszerűbbé tehetik ezt a munkát, mert amint az 1. pontban említettük, valójában nem kell tudnod, mi az eszköz mögöttes rétege.

  2. Végül a Felhő eseménye - Minden a felhő felé halad. Az alkalmazások lassan áttérnek a felhőalapú rendszerekre, például az Azure-ba vagy az Amazon-ba. Az Azure és az Amazon sok API-t biztosít a Restful architektúrán alapulva. Ezért az alkalmazásokat most úgy kell fejleszteni, hogy azok kompatibilisek legyenek a felhővel. Tehát mivel minden felhőalapú architektúra a REST elvén működik, ésszerűbb, ha a webszolgáltatásokat a REST szolgáltatásalapú architektúrára kell programozni, hogy a lehető legjobban kihasználják a felhőalapú szolgáltatásokat.

Nyugodt építészet

A RESTful vagy REST stílusúnak tekintett alkalmazás vagy architektúra a következő jellemzőkkel rendelkezik

  1. Az állapot és a funkcionalitás elosztott erőforrásokra oszlik - Ez azt jelenti, hogy minden erőforrásnak elérhetőnek kell lennie a GET, POST, PUT vagy DELETE szokásos HTTP parancsokkal. Tehát, ha valaki egy szerverről szeretett volna fájlt szerezni, akkor képesnek kell lennie a GET kérés kiadására és a fájl megszerzésére. Ha fájlt akarnak feltenni a szerverre, akkor képesnek kell lenniük a POST vagy PUT kérelem kiadására. És végül, ha törölni akarnak egy fájlt a szerverről, kiadják a DELETE kérést.
  2. Az architektúra kliens / szerver, hontalan, réteges és támogatja a gyorsítótárat -
  • A kliens-kiszolgáló az a tipikus architektúra, ahol a kiszolgáló lehet az alkalmazást tároló webkiszolgáló, és az ügyfél lehet olyan egyszerű, mint a webböngésző.
  • A hontalan azt jelenti, hogy az alkalmazás állapota nincs fenntartva a REST-ben.

    Például, ha töröl egy erőforrást a kiszolgálóról a DELETE paranccsal, akkor nem számíthat arra, hogy a törlési információk átkerülnek a következő kérelemhez.

    Az erőforrás törlésének biztosításához ki kell adnia a GET kérést. A GET kérést arra használnák, hogy először a szerver összes erőforrását megszerezze. Ezután meg kell nézni, hogy az erőforrást valóban törölték-e.

RESTFul alapelvek és korlátozások

A REST architektúra néhány jellemzőn alapul, amelyeket az alábbiakban részletezünk. Bármely RESTful webszolgáltatásnak meg kell felelnie az alábbi jellemzőknek ahhoz, hogy RESTfulnak lehessen nevezni. Ezeket a jellemzőket tervezési alapelveknek is nevezik, amelyeket be kell tartani, amikor a RESTful alapú szolgáltatásokkal dolgoznak.

  1. RESTFul kliens-kiszolgáló

Ez a REST alapú architektúra legalapvetőbb követelménye. Ez azt jelenti, hogy a kiszolgálónak RESTful webszolgáltatása lesz, amely biztosítja a kliens számára a szükséges funkciókat. Az ügyfél kérést küld a szerver webszolgáltatásához. A szerver vagy elutasítja a kérést, vagy eleget tesz, és megfelelő választ ad az ügyfélnek.

  1. Hontalan

A hontalanok fogalma azt jelenti, hogy az ügyfél feladata biztosítani, hogy az összes szükséges információt megkapja a szerver. Erre azért van szükség, hogy a szerver megfelelően tudja feldolgozni a választ. A kiszolgálónak nem szabad semmiféle információt fenntartania az ügyfél kérései között. Ez egy nagyon egyszerű független kérdés-válasz sorrend. Az ügyfél feltesz egy kérdést, a szerver megfelelően válaszol rá. Az ügyfél újabb kérdést tesz fel. A szerver nem emlékszik az előző kérdés-válasz forgatókönyvre, és önállóan kell válaszolnia az új kérdésre.

  1. Gyorsítótár

A Cache koncepció segít a hontalanok problémájában, amelyet az utolsó pont ismertetett. Mivel minden kiszolgáló kliens kérése független jellegű, előfordulhat, hogy az ügyfél újra megkéri a szervertől ugyanazt a kérést. Ez annak ellenére történt, hogy már korábban is kérte. Ez a kérés eljut a szerverhez, és a szerver választ ad. Ez növeli a forgalmat a hálózaton keresztül. A gyorsítótár egy olyan koncepció, amely az ügyfélen valósul meg a szerverre már elküldött kérelmek tárolására. Tehát, ha ugyanazt a kérést adja meg az ügyfél, ahelyett, hogy a szerverre menne, akkor a gyorsítótárba megy, és megkapja a szükséges információkat. Ez megtakarítja az ügyfél és a szerver közötti hálózati forgalom mennyiségét.

  1. Réteges rendszer

A réteges rendszer koncepciója, hogy minden további réteg, például egy köztes réteg, beilleszthető az ügyfél és a RESTFul webszolgáltatást tároló tényleges kiszolgáló közé (A közbenső réteget az üzleti logika egésze létrehozza. Ez extra szolgáltatás lehet. amelyet az ügyfél kölcsönhatásba léphet, mielőtt felhívja a webszolgáltatást.). De ennek a rétegnek a bevezetésének átláthatónak kell lennie, hogy ne zavarja az ügyfél és a szerver közötti interakciót.

  1. Interfész / Egységes szerződés

Ez a RESTful webszolgáltatások működésének alaptechnikája. A RESTful alapvetően a HTTP webrétegen működik, és az alábbi kulcsigékkel használja a szerver erőforrásait

  • POST - Erőforrás létrehozása a szerveren
  • GET - Erőforrás lekérése a szerverről
  • PUT - Az erőforrás állapotának megváltoztatása vagy frissítése
  • TÖRLÉS - Erőforrás eltávolítása vagy törlése a szerverről

Készítse el első nyugodt webszolgáltatását az ASP.NET-ben

Ebben a REST API oktatóanyagban megtanulhatjuk, hogyan hozzunk létre egy nyugodt webszolgáltatást az ASP.NET-ben:

A webszolgáltatások különféle nyelveken hozhatók létre. Számos integrált fejlesztői környezet használható REST alapú szolgáltatások létrehozására.

Ebben a RESTful API példában a Visual Studio használatával létrehozzuk a REST alkalmazást a .Net-ben. Példánkban a Restful webszolgáltatások esetében a következő REST szolgáltatás példát fogjuk utánozni.

Nyugodt webszolgáltatásunk lesz, amely az alábbi adatkészleten fog működni.

Az alábbi adatkészlet egy REST API példát mutat be arra vonatkozóan, hogy van-e olyan cégünk, amely bemutatja az Oktatóanyagot, amelyet a Tutorialid alapján készítettek.

Tutorialid TutorialName
0 Tömbök
1 Sorok
2 Verem

A REST API oktató példánkban az alábbi Nyugtató igéket fogjuk megvalósítani.

  1. GET Tutorial - Amikor az ügyfél meghívja ezt a Restful API-t, megkapja a webszolgáltatásban elérhető oktatóanyagok teljes készletét.
  2. GET Tutorial / Tutorialid - Amikor az ügyfél meghívja ezt a Restful API-t, akkor az oktató nevet kapja az ügyfél által küldött Tutorialid alapján.
  3. POST oktatóanyag / oktatóanyag neve - Amikor az ügyfél meghívja ezt a Restful API-t, az ügyfél kérelmet nyújt be a Tutorialname beszúrására. A webszolgáltatás ezután hozzáadja a beküldött oktatóanyag nevét a gyűjteményhez.
  4. Tutorial / Tutorialid törlése - Amikor az ügyfél meghívja ezt a Restful API-t, az ügyfél kérelmet nyújt be a Tutorialid alapján egy Tutorialname törlésére. A webszolgáltatás ezt követően törli a beküldött oktatóanyag nevét a gyűjteményből.

Kövessük a RESTful API oktatóanyag alábbi lépéseit az első RESTful webes szolgáltatásaink létrehozásához, amelyek végrehajtják a fenti megvalósítást.

1. lépés: Az első lépés egy üres Asp.Net webalkalmazás létrehozása. A Visual Studio 2013 alkalmazásban kattintson a Fájl-> Új projekt menüpontra.

Miután rákattint az Új projekt opcióra, a Visual Studio megad egy újabb párbeszédpanelt a projekt típusának kiválasztásához és a projekt szükséges részleteinek megadásához. Ezt a RESTful API oktatóanyag következő lépésében ismertetjük

2. lépés) Ebben a lépésben

  1. Először válassza ki az ASP.NET webalkalmazás RESTful webszolgáltatások C # websablonját. A projektnek ilyen típusúnak kell lennie a webszolgáltatási projekt létrehozásához. Ezen opciók kiválasztásával a Visual Studio elvégzi a szükséges lépéseket a szükséges fájlok hozzáadásához, amelyekre bármely webalapú alkalmazás szükséges.
  2. Adjon nevet a projektjének, amelyet esetünkben "Webservice.REST" néven kaptak.
  3. Ezután adjon meg egy helyet, ahol a projektfájlok tárolódnak.

Ha elkészült, látni fogja a Visual Studio 2013-ban a megoldásfelfedezőben létrehozott projektfájlt.

3. lépés: A következő lépés egy olyan webszolgáltatási fájl létrehozása, amely a RESTful webszolgáltatással rendelkezik

  1. Először kattintson jobb gombbal a projektfájlra az alábbiak szerint
  1. Ebben a lépésben
    1. Kattintson a jobb gombbal a projektfájlra
    2. Válassza az "Add-> new item" opciót.

A megjelenő párbeszédpanelen a következőket kell végrehajtania

  1. Válassza a WCF szolgáltatás (Ajax-kompatibilis) opciót - Válasszon egy ilyen típusú fájlt, ez a Visual stúdiónak hozzáad néhány alapvető kódot, amely segít egy RESTful webszolgáltatás létrehozásában. A WCF a Windows Communication Foundation rövidítését jelenti. A WCF egy könyvtár különböző platformok vagy ugyanazon platform alkalmazásai számára, amelyek a különböző protokollok, például TCP, HTTP, HTTPS, kommunikációjára szolgálnak. Az Ajax alapvetően aszinkron JavaScript és XML. Az AJAX lehetővé teszi a weboldalak aszinkron frissítését azáltal, hogy kis mennyiségű adatot cserél a szerverrel a kulisszák mögött.
  2. Ezután adjon nevet a szolgáltatásnak, amely esetünkben a TutorialService.
  3. Végül kattintson a Hozzáadás gombra a szolgáltatás hozzáadásához a megoldáshoz.

4. lépés: A következő lépés a konfiguráció tényleges módosítása, hogy a projekt befejezhesse a RESTful webszolgáltatásokkal való munkát. Ehhez meg kell változtatni a Web.config nevű fájlt . Ez a fájl ugyanabban az ablakban jelenik meg, mint a Webservice projektfájl. A Web.config fájl tartalmazza az összes olyan konfigurációt, amely a webalkalmazást a megfelelő módon működik. A végrehajtott módosítás valójában lehetővé teszi az alkalmazás számára, hogy tiszta RESTful webszolgáltatásként küldjön és fogadjon adatokat.

  1. Kattintson a Web.config fájlra a kód megnyitásához
  1. Keresse meg az sort
  1. Változtassa a sort -ra

5. lépés) A RESTful API oktatóanyagának következő lépése a kód hozzáadása a megvalósításhoz. Az összes alább említett kódot be kell írni a TutorialService.svc fájlba

  1. Az első bit kód hozzáadása, amely a programunkban használt adatainkat ábrázolja. Tehát lesz egy listánk a string változókról, amelyek értéke "tömbök", "várólisták" és "halmok". Ez a tárhely webes szolgáltatásunkon keresztül elérhető oktatóanyagok nevét fogja jelenteni.
namespace Webservice.REST{[ServiceContract(Namespace = "")][AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowedpublic class TutorialService{private static List  lst = new List  (new String[] {"Arrays","Queues","Stacks"});

6. lépés) Ezután meghatározzuk a GET módszer kódját. Ez a kód szintén ugyanabban a TutorialService.svc fájlban található. Ez a kód akkor fog futni, amikor a böngészőnkből hívjuk a szolgáltatást.

Az alábbi módszert fogják használni az alább említett forgatókönyv megvalósításához

  • Ha egy felhasználó az összes rendelkezésre álló oktatóanyag listáját akarja, akkor ennek végrehajtásához az alábbi kódot kell írni.
[WebGet(UriTemplate="/Tutorial")]public String GetAllTutorial(){int count = 1st.Count;String TutorialList = "";for (int i = 0; i < count; i++)TutorialList = TutorialList + lst[i] + ",";return TutorialList;}

Kód Magyarázat: -

  1. Az első kódsor a legfontosabb. Meghatározzák, hogyan hívhatjuk meg ezt a módszert egy URL-en keresztül. Tehát ha a webszolgáltatásunkra mutató link http: // localhost: 52645 / TutorialService.svc, és ha a '/ Tutorial' címet az URL-hez http: // localhost: 52645 / TutorialService.svc / Tutorial csatoljuk , a fenti kódot hivatkozni fognak. A 'WebGet' attribútuma egy olyan paraméter, amely lehetővé teszi, hogy ez a módszer RESTful módszer legyen, és így a GET igével lehívható legyen.
  2. Ez a kódrész arra szolgál, hogy végigvigye az 'lst' változóban szereplő karakterlánc-listánkat, és mindegyiket visszaadja a hívó programnak.

7. lépés: Az alábbi kód biztosítja, hogy ha egy GET hívást kezdeményeznek az oktatószolgáltatáshoz egy oktató azonosítóval, akkor az az oktató azonosító alapján visszaadja a megfelelő oktató nevet.

[WebGet (UriTemplate = "/Tutorial/{Tutorialid}")]public String GetTutorialbyID(String Tutorialid){int pid;Int32.TryParse(Tutorialid, out pid);return lst[pid];}

Kód Magyarázat: -

  1. Az első kódsor a legfontosabb. Meghatározzák, hogyan hívhatjuk meg ezt a módszert egy URL-en keresztül. Tehát, ha a webszolgáltatásunkra mutató link http: // localhost: 52645 / TutorialService.svc, és ha az URL-hez csatoljuk a '/ Tutorial / {Tutorialid}' elemet , akkor a webszolgáltatást http- ként hívhatnánk : //localhost:52645/TutorialService.svc/Tutorial/1 példaként. A webszolgáltatásnak vissza kell adnia az oktatóanyag nevét, amelynek az 1. oktatóazonosítója volt.
  2. Ez a kódrész arra szolgál, hogy visszaadja az "oktatóanyag nevét", amelynek oktatóanyag-azonosítóját átadta a webes módszernek.
  • Alapértelmezés szerint arra kell emlékezni, hogy bármi, amit a böngészőben továbbítanak az URL-re, sztring.
  • De emlékeznie kell arra, hogy a listánk indexének egész számnak kell lennie, ezért hozzáadjuk a szükséges kódot, hogy először átalakítsuk a Tutorialid egész számra, majd felhasználjuk a listánk indexpozíciójának eléréséhez, és
  • Ezután adja vissza az értéket a hívó programnak ennek megfelelően.

8. lépés: A következő lépés a POST módszer kódjának felírása. Erre a módszerre akkor kerül sor, amikor a POST metódussal hozzá akarunk adni egy karaktersorozatot az oktatóanyagok listájához. Például, ha hozzá szeretné adni a "Szoftvertesztelés" oktatóanyag nevét, akkor a POST metódust kell használnia.

Kód Magyarázat: -

  1. Az első sor a "WebInvoke" attribútum, amelyet a módszerünkhöz csatoltunk. Ez lehetővé teszi a módszer meghívását a POST híváson keresztül. A RequestFormat és a ResponseFormat attribútumokat JSON néven kell megemlíteni, mivel amikor egy RESTFul webszolgáltatásba küld értékeket, akkor az értékeknek ebben a formátumban kell lenniük.
  2. A második kódsor arra szolgál, hogy a POST híváson keresztül továbbított karaktersorozatot hozzáadjuk az oktatói karakterláncok meglévő listájához.

9. lépés) Végül hozzáadjuk a módszerünket a DELETE művelet kezeléséhez. Erre a módszerre akkor kerül sor, amikor a DELETE módszerrel törölni akarunk egy meglévő karakterlánc-értéket az oktatóanyagok listájáról.

[WebInvoke(Method = "DELETE", RequestFormat = WebMessageFormat.Ison,UriTemplate = "/Tutorial/{Tutorialid}", ResponseFormat = WebMessageFormat.Json,BodyStyle = WebMessageBodyStyle.Wrapped)]public void DeleteTutorial(String Tutorialid){int pid;Int32.TryParse(Tutorialid, out pid);1st.RemoveAt(pid);}

Kód Magyarázat: -

  1. Az első sor a "WebInvoke" attribútum, amelyet a módszerünkhöz csatoltunk. Ez lehetővé teszi a módszer meghívását a POST híváson keresztül. A RequestFormat és a ResponseFormat attribútumokat JSON néven kell megemlíteni, mivel amikor egy RESTFul webszolgáltatásba küld értékeket, akkor az értékeknek ebben a formátumban kell lenniük. Vegye figyelembe, hogy a Method paraméter értéke "DELETE". Ez azt jelenti, hogy amikor kiadjuk a DELETE igét, akkor erre a módszerre lesz szükség.
  2. A második kódsor a DELETE híváson keresztül elküldött Tutorialid elfogadására szolgál, majd ezt az azonosítót törli a listánkból. (A kódban szereplő Int32 függvény az oktatóanyag-azonosító karakterlánc-változóból egész számgá történő átalakítására szolgál.)

Az első nyugodt webszolgáltatás futtatása

Most, hogy létrehoztuk a teljes webes szolgáltatásunkat a fenti szakaszban. Nézzük meg, hogyan futtathatjuk az Oktatószolgáltatást úgy, hogy bármely ügyfél meghívható legyen.

A webszolgáltatás futtatásához kövesse az alábbi lépéseket

1. lépés: Kattintson a jobb gombbal a Projekt fájlra - Webservice.REST

2. lépés: Válassza a „Beállítás StartUp projektként” menüpontot. Ez biztosítja a projekt futtatását, amikor a Visual Studio futtatja a teljes megoldást

3. lépés: A következő lépés maga a projekt futtatása. Most, a rendszerre telepített alapértelmezett böngészőtől függően, a megfelelő böngésző neve a Visual Studio futtató gombja mellett jelenik meg. Esetünkben megjelenik a Google Chrome. Csak kattintson erre a gombra.

Kimenet:-

A projekt futtatása után böngészhet a TutorialService.svc / Tutorial szakaszban, és megkapja az alábbi kimenetet.

A fenti kimenetben

  • Láthatja, hogy a böngésző a „GET” igét hívja meg, és végrehajtja a „GetAllTutorial” metódust a webszolgáltatásban. Ez a modul a webszolgáltatásunk által kitett összes oktatóanyag megjelenítésére szolgál.

Az első nyugodt webszolgáltatás tesztelése

A fenti szakaszban már láttuk, hogyan lehet a böngészővel végrehajtani a „GET” igét és meghívni a „GetAllTutorial” -t.

  1. Most használjuk a böngészőt a következő használati eset végrehajtásához.

GET Tutorial / Tutorialid - Amikor az ügyfél meghívja ezt a Restful API-t, akkor az oktató nevet kapja az ügyfél által küldött Tutorialid alapján.

Böngészőjében fűzze hozzá a / 1 karakterláncot az URL-ben szereplő Oktatószó után. Ha megnyomja az Enter gombot, megkapja az alábbi kimenetet

Most látni fogja a várólisták kimenetét, amely valójában megfelel az Oktatófüzérek listánk 1. számának. Ez azt jelenti, hogy a 'GetTutorialbyID' metódust most meghívjuk webszolgáltatásunkból. Ez azt is mutatja, hogy az 1 értéket a böngészőn keresztül sikeresen továbbítják a webszolgáltatásunknak és a módszerünknek, és ezért kapjuk meg a böngészőben a megfelelő "Sorok" értéket.

  1. Ezután fogyasszuk el webszolgáltatásunkat az alábbi forgatókönyv végrehajtásával. Ehhez telepítenie kell a "Fiddler" nevű eszközt, amely egy ingyenesen letölthető eszköz a webhelyről.

POST oktatóanyag / oktatóanyag neve - Amikor az ügyfél meghívja ezt a Restful API-t, az ügyfél kérelmet nyújt be a Tutorialname beszúrására. A webszolgáltatás ezután hozzáadja a beküldött oktatóanyag nevét a gyűjteményhez.

Futtassa a Filddler eszközt, és hajtsa végre az alábbi lépéseket;

  1. Ugrás a zeneszerző részre. Ezt olyan kérelmek létrehozására használják, amelyek bármely webre benyújthatók

    Alkalmazás.

  2. Győződjön meg arról, hogy a kérés típusa "POST", és a helyes URL-t találja meg, amelynek esetünkben http: // localhost: 52645 / TutorialService.svc / Tutorial
  3. Győződjön meg arról, hogy a Content-Type alkalmazás / json jelöléssel van ellátva. Ne feledje, hogy a webszolgáltatásunk POST kérési módszere csak a json stílus adatait fogadja el, ezért biztosítanunk kell, hogy ezt megadjuk, amikor kérelmet küldünk alkalmazásunknak.
  4. Végül meg kell adnunk az adatainkat. Ne feledje, hogy a POST módszerünk elfogadja az 'str' nevű paramétert. Tehát itt megadjuk, hogy hozzá akarunk adni egy "Fák" nevű értéket az oktatóanyagok nevének gyűjteményéhez, és biztosítani kell, hogy az az str változó nevéhez legyen címkézve.

Végül csak kattintson a Végrehajtás gombra a hegedűsben. Ez kérelmet küld a webszolgáltatásnak, hogy POST-osítsa a "Fák" adatot webszolgáltatásunkhoz.

Most, amikor a Bemutató URL-re böngészünk, hogy megmutassuk a Bemutató lista összes karakterláncát, akkor látni fogja, hogy a "Fák" értéke is jelen van. Ez azt mutatja, hogy a webszolgáltatás POST kérését sikeresen végrehajtották, és hogy sikeresen felvették az oktatóanyagok listájába.

  1. Ezután fogyasszuk el webszolgáltatásunkat az alábbi forgatókönyv végrehajtásával. Ehhez szintén a hegedűs eszközt kell használnunk

Tutorial / Tutorialid törlése - Amikor az ügyfél meghívja ezt a Restful API-t, az ügyfél kérelmet nyújt be a Tutorialid alapján egy Tutorialname törlésére. A webszolgáltatás ezt követően törli a beküldött oktatóanyag nevét a gyűjteményből.

Futtassa a Filddler eszközt, és hajtsa végre az alábbi lépéseket

  1. Ugrás a zeneszerző részre. Ezt olyan kérelmek létrehozására használják, amelyek bármely webre benyújthatók

    Alkalmazás.

  2. Győződjön meg arról, hogy a kérés típusa "TÖRLÉS", és a helyes URL-t találja, amely esetünkben a következő legyen : http: // localhost: 52645 / TutorialService.svc / Tutorial . Győződjön meg arról, hogy az azonosító, amelyet egy karakterlánc törléséhez használnak az URL-n keresztül paraméterként elküldött listából. A REST példánkban 1-et küldünk, így ez törli a gyűjteményünk második elemét, amely a "Sorok".

Végül csak kattintson a Végrehajtás gombra a hegedűsben. Ez egy kérést fog küldeni a webszolgáltatásnak, hogy törölje az "Sorok" adatot webszolgáltatásunkhoz.

Most, amikor az oktatóanyag URL-jére böngészünk, hogy bemutassuk az oktatóanyag-listánk összes karakterláncát, akkor észreveszi, hogy a "Sorok" értéke már nincs jelen.

Ez azt mutatja, hogy a webszolgáltatáshoz tartozó DELETE kérés sikeresen végrehajtásra került. A Tutorial húrok listáján az 1. indexen található elemet sikeresen törölte.

Összegzés

  • A REST jelentése REpresentational State Transfer. A REST segítségével könnyű, karbantartható és méretezhető webszolgáltatásokat készítenek.
  • Egyre több alkalmazás költözik a Restful architektúrára. Ennek oka az, hogy sok ember használ mobileszközöket, és szélesebb körű alkalmazások költöznek a felhőbe.
  • A REST fő szempontjai a szerveren található erőforrások, valamint a GET, POST, PUT és DELETE igék, amelyek felhasználhatók az erőforrásokkal való együttműködésre.
  • A Visual Studio és a.Net segítségével nyugodt webszolgáltatásokat lehet létrehozni.
  • A webszolgáltatások POST és PUT tesztelésénél egy másik eszközt kell használni, a fiddler nevet, amely segítségével elküldheti a POST és PUT kérést a szerverre.