RESTful webszolgáltatások oktatóanyaga: REST API példa

Miért érdemes Restful webszolgáltatásokat használni?

Mielőtt belemennénk a technikai részletekbe, érdemes megérteni, miért lett a REST ilyen népszerű. A RESTful webszolgáltatások a következő okok miatt váltak ismertté:

1. Heterogén nyelvek és környezetek – Ez az egyik alapvető ok, ami ugyanaz, mint amit már láttunk a ... esetében is. SOAP is.

• Lehetővé teszi a különböző programozási nyelveken készült webes alkalmazások egymás közötti kommunikációját.
• A Restful szolgáltatások segítségével ezek a webes alkalmazások különböző környezetekben is elhelyezkedhetnek; némelyikük lehet Windows, és mások is lehetnek Linuxon.

Végső soron, bármilyen környezetről is legyen szó, az eredménynek mindig ugyannak kell lennie: az alkalmazásoknak képesnek kell lenniük egymással kommunikálni. A Restful webszolgáltatások ezt a rugalmasságot kínálják a különféle programozási nyelveken és platformokon készült alkalmazások számára.

Az alábbi kép egy olyan webes alkalmazást mutat be, amelynek kommunikálnia kell más alkalmazásokkal, például a Facebookkal, a Twitterrel és másokkal. Google.

Ha egy kliensalkalmazásnak olyan oldalakkal kellene együttműködnie, mint a Facebook és a Twitter, a fejlesztőknek általában tudniuk kellene, hogy ezek az oldalak milyen nyelven és platformon épülnek. Ennek alapján megírhatnák a csatlakozókódot, de ennek a megközelítésnek a fenntartása rémálomnak bizonyulhat.

Ehelyett a Facebook, a Twitter és Google Restful webszolgáltatások formájában teszik elérhetővé funkcionalitásukat. Ez lehetővé teszi bármely kliensalkalmazás számára, hogy REST-en keresztül hívja meg ezeket a webszolgáltatásokat, függetlenül az alapul szolgáló technológiától.

2. Az Eszközök eseménye – Manapság mindennek működnie kell Mobil eszközök, legyen az mobiltelefon, notebook vagy akár egy autós rendszer.

Képzeljük el, mennyi erőfeszítést igényel az alkalmazások kódolása ezeken az eszközökön, hogy kommunikáljanak a normál webes alkalmazásokkal. A Restful API-k ismét egyszerűbbé teszik ezt a feladatot, mert – ahogy az első pontban említettük – valójában nem kell ismerni az eszköz mögöttes rétegét.

3. A Felhő eseménye – Minden a felhőbe költözik. Az alkalmazások lassan átköltöznek a felhőalapú rendszerekbe, mint például Azure or Amazon. Azure és a Amazon számos Restful architektúrán alapuló API-t biztosítanak. Ezért az alkalmazásokat most úgy kell fejleszteni, hogy kompatibilisek legyenek a felhővel. Mivel minden felhőalapú architektúra a REST elven működik, logikus, hogy a webszolgáltatásokat REST-alapú architektúrán programozzák a felhőszolgáltatások legjobb kihasználása érdekében.

RESTful Key Elements

A REST webszolgáltatások hosszú utat tettek meg a kezdeteik óta. 2002-ben a Web konzorcium kiadta a WSDL és a SOAP webszolgáltatások definícióját. Ez képezte a webszolgáltatások megvalósításának szabványát.

2004-ben a webes konzorcium kiadta egy további szabvány, a RESTful definícióját is. Az elmúlt években ez a szabvány meglehetősen népszerűvé vált, és ma már a világ számos népszerű weboldala használja, köztük a Facebook és a Twitter.

A REST egy módja annak, hogy egy adott környezetben található erőforrásokhoz férjünk hozzá. Például lehet egy szerverünk, amely fontos dokumentumokat, képeket vagy videókat tárol. Mindezek példák az erőforrásokra. Ha egy kliensnek, például egy webböngészőnek, szüksége van ezekre az erőforrásokra, akkor kérést kell küldenie a szervernek. A REST szolgáltatások meghatározzák ezen erőforrások elérésének szabványos módját.

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

1. Tudástár – Az első kulcsfontosságú elem maga az erőforrás. Tegyük fel, hogy egy szerveren lévő webalkalmazás több alkalmazott rekordjaival rendelkezik. Tegyük fel, hogy a URL a webes alkalmazás https://demo.guru99.comMost, ahhoz, hogy egy alkalmazotti rekord erőforrást REST szolgáltatásokon keresztül érjünk el, kiadhatjuk a következő parancsot: https://demo.guru99.com/employee/1Ez a parancs arra utasítja a webszervert, hogy adja meg az 1-es számú alkalmazott adatait.
2. Igék kérése – Ezek leírják, hogy mit szeretne tenni az erőforrással. Egy böngésző egy GET parancsot ad ki, hogy utasítsa a végpontot az adatok lekérésére. Azonban számos más parancs is elérhető, többek között a POST, PUT és DELETE. Tehát a példa esetében https://demo.guru99.com/employee/1, a webböngésző valójában egy GET műveletet ad ki, mivel meg akarja szerezni az alkalmazotti rekord részleteit.
3. Kérjen fejléceket – Ezek a kéréshez mellékelt további utasítások. Meghatározhatják a kért válasz típusát vagy az engedélyezési részleteket.
4. Kérelem szerve – Ez a kéréssel együtt küldött adat. Az adatokat általában a kérés törzsében küldik, amikor POST kérést küldenek a REST webszolgáltatásnak. Egy POST hívás során az ügyfél közli a REST webszolgáltatással, hogy erőforrást szeretne hozzáadni a szerverhez. Így a kérés törzse tartalmazza a hozzáadandó erőforrás részleteit.
5. Választest – Ez a válasz törzse. Tehát a RESTful API példánkban, ha a kérésen keresztül kérdeznénk le a webszervert https://demo.guru99.com/employee/1, a webszerver egy XML dokumentumot adhat vissza, amely a válasz törzsében tartalmazza az alkalmazott összes adatát.
6. Válasz állapotkódok – Ezek az általános kódok, amelyeket a webszerver a válasszal együtt visszaad. Példa erre a 200-as kód, amelyet általában akkor ad vissza a rendszer, ha nincs hiba a kliensnek küldött válasz során.

Pihentető módszerek

Az alábbi ábra a legtöbb műveletet (POST, GET, PUT és DELETE) mutatja be, valamint egy REST API példát arra vonatkozóan, hogy mit jelentenek.

Tegyük fel, hogy van egy RESTful webszolgáltatásunk definiálva a következő helyen: https://demo.guru99.com/employeeAmikor a kliens bármilyen kérést küld ehhez a webszolgáltatáshoz, megadhatja a GET, POST, DELETE és PUT szokásos HTTP-műveletek bármelyikét. Az alábbiakban látható, hogy mi történne, ha a megfelelő műveleteket a kliens küldené.

1. POST – Ezt egy új alkalmazott létrehozásához használnánk a RESTful webszolgáltatás használatával.
2. GET – Ezzel lekérhető az összes RESTful webszolgáltatást használó alkalmazott listája.
3. PUT – Ezzel frissítenék az összes RESTful webszolgáltatást használó alkalmazott adatait.
4. DELETE – Ezzel törölnénk az összes RESTful szolgáltatást használó alkalmazottat.

Most nézzük meg egyetlen rekord szemszögéből. Tegyük fel, hogy van egy alkalmazotti rekord, amelynek alkalmazotti száma 1. A következő műveleteknek megvan a saját jelentésük.

1. POST – Ez nem lenne alkalmazható, mivel az 1. alkalmazott adatait kérjük le, amelyek már létre vannak hozva.
2. GET – Ezt használnánk az 1-es számú alkalmazott adatainak lekérésére a RESTful webszolgáltatás használatával.
3. PUT – Ez az 1-es számú alkalmazott adatainak frissítésére szolgálna a RESTful webszolgáltatás használatával.
4. DELETE – Ezzel törölhetők az 1-es számú alkalmazott adatai.

Nyugalmas Architectúra

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

1. Az állapot és a funkcionalitás elosztott erőforrásokra van felosztva – Ez azt jelenti, hogy minden erőforrásnak elérhetőnek kell lennie a GET, POST, PUT vagy DELETE normál HTTP parancsokkal. Tehát, ha valaki egy fájlt szeretne lekérni egy szerverről, akkor képesnek kell lennie a GET kérés kiadására és a fájl lekérésére. Ha egy fájlt fel akar tenni a szerverre, akkor képesnek kell lennie a POST vagy a PUT kérés kiadására. Végül, ha törölni akar egy fájlt a szerverről, akkor DELETE kérést adhat ki.

2. Az architektúra kliens/szerver, állapot nélküli, rétegzett és támogatja a gyorsítótárazást.

• A kliens-szerver az a tipikus architektúra, ahol a szerver lehet az alkalmazást kiszolgáló webszerver, a kliens pedig olyan egyszerű, mint a webböngésző.
• Az állapot nélküli azt jelenti, hogy az alkalmazás állapotát a REST nem tartja fenn. Ha például a DELETE paranccsal töröl egy erőforrást egy kiszolgálóról, akkor nem számíthat arra, hogy a törlési információkat átadja a következő kérésnek.

Annak érdekében, hogy az erőforrás törlődjön, GET kérést kell küldeni. A GET kérést először a szerveren található összes erőforrás lekérésére használnánk, majd ellenőrizni kellene, hogy az erőforrás valóban törölve lett-e.

RESTFul elvek és korlátok

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 RESTful-nak nevezhessék. Ezeket a jellemzőket tervezési elveknek is nevezik, amelyeket a RESTful-alapú szolgáltatásokkal való munka során be kell tartani.

1. RESTFul Client-Server

   

Ez a REST-alapú architektúra legalapvetőbb követelménye. Ez azt jelenti, hogy a szervernek rendelkeznie kell egy RESTful webszolgáltatással, amely biztosítja a kliens számára a szükséges funkciókat. A kliens kérést küld a szerveren található webszolgáltatásnak. A szerver ezután vagy elutasítja a kérést, vagy eleget tesz annak, és megfelelő választ ad a kliensnek.

2. hontalan

Az állapot nélküliség koncepciója azt jelenti, hogy a kliens feladata biztosítani, hogy a szerver megkapja az összes szükséges információt. Erre azért van szükség, hogy a szerver megfelelően feldolgozhassa a választ. A szervernek nem szabad semmilyen információt megőriznie a klienstől érkező kérések között. Ez egy nagyon egyszerű, független kérdés-válasz sorozat. A kliens feltesz egy kérdést, és a szerver megfelelően válaszol rá. Amikor a kliens egy másik kérdést tesz fel, a szerver nem emlékszik az előző kérdés-válasz szekvenciára, és az új kérdésre függetlenül kell válaszolnia.

3. Gyorsítótár

A gyorsítótár koncepciója segít az előző pontban leírt állapotnélküliség problémáján. Mivel minden szerver-kliens kérés független természeténél fogva, előfordulhat, hogy a kliens újra kéri a szervertől ugyanazt a kérést, annak ellenére, hogy korábban már kérte azt. Ez a kérés a szerverhez kerül, és a szerver választ ad, ami növeli a hálózaton keresztüli forgalmat. A gyorsítótár egy olyan koncepció, amelyet a kliensen valósítottak meg, hogy tárolja a szervernek már elküldött kéréseket. Tehát, ha a kliens ugyanazt a kérést adja, ahelyett, hogy a szerverhez menne, a gyorsítótárba kerülne, és megkapja a szükséges információkat. Ez megspórolja a kliens és a szerver közötti oda-vissza hálózati forgalmat.

4. Réteges rendszer

A réteges rendszer koncepciója szerint bármilyen további réteg, például egy köztes réteg, beilleszthető a kliens és a RESTFul webszolgáltatást futtató tényleges szerver közé. (A köztes rétegben jön létre az összes üzleti logika. Ez lehet egy extra szolgáltatás, amellyel a kliens interakcióba lép, mielőtt meghívja a webszolgáltatást.) Ennek a rétegnek a bevezetésének azonban átláthatónak kell lennie, hogy ne zavarja a kliens és a szerver közötti interakciót.

5. Interfész/Egységes Contract

Ez az alapvető technika, amelyen a RESTful webszolgáltatásoknak működniük kellene. A RESTful alapvetően a HTTP webes rétegen működik, és az alábbi kulcsigéket használja a szerveren lévő erőforrásokkal való munkához.

• POST – Erőforrás létrehozása a szerveren.
• GET – Erőforrás lekérése a szerverről.
• PUT – Egy 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.

REST vs. SOAP: Főbb különbségek

A fejlesztők gyakran mérlegelik a REST és a SOAP közötti különbséget webszolgáltatások tervezésekor. Mindkettő lehetővé teszi az elosztott alkalmazások kommunikációját, de filozófiájukban élesen eltérnek. A REST egy olyan architektúra, amely egyszerű HTTP-verbeket és könnyűsúlyú formátumokat, például JSON-t használ, míg SOAP egy szigorú protokoll, amely XML borítékokra és egy formális konverzióra támaszkodik.tract. Az alábbi táblázat összefoglalja a legfontosabb különbségeket.

A gyakorlatban a REST az alapértelmezett választás a nyilvános webes és mobil API-khoz, mivel gyorsabb és könnyebben használható, míg a SOAP továbbra is hasznos a beépített biztonságot és formális ellenőrzést igénylő vállalati rendszerek számára.tracts.

Hozza létre első Restful webszolgáltatását az ASP.NET-ben

Ebben a REST API oktatóanyagban most megtanuljuk, hogyan hozhatunk létre Restful webszolgáltatást ASP.NET-ben.

A webszolgáltatások számos nyelven létrehozhatók, és 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 REST alkalmazásunkat fogjuk létrehozni .NET-ben a Visual Studio használatával. Lesz egy Restful webszolgáltatásunk, amely az alábbi adathalmazon fog működni.

Az alábbi adathalmaz egy REST API példát mutat be egy olyan vállalatról, amely a Tutorialid alapján teszi közzé az oktatóanyagait.

A REST API bemutató példánkban az alábbi Restful műveleteket fogjuk megvalósítani.

1. GET Tutorial – Amikor egy kliens meghívja ezt a Restful API-t, megkapja a webszolgáltatásban elérhető összes oktatóanyagot.
2. GET Tutorial/Tutorialid – Amikor egy kliens meghívja ezt a Restful API-t, a kliens által küldött Tutorialid alapján megkapja a bemutató nevét.
3. POST oktatóanyag/oktatóanyag neve – Amikor egy kliens meghívja ezt a Restful API-t, a kliens egy kérést küld be egy oktatóanyagnév beillesztésére. A webszolgáltatás ezután hozzáadja a beküldött oktatóanyag nevét a gyűjteményhez.
4. Oktatóanyag/Oktatóanyag TÖRLÉSE – Amikor egy kliens meghívja ezt a Restful API-t, a kliens egy kérést küld be a Tutorialid alapján létrehozott Tutorialname törlésére. A webszolgáltatás ezután törli a beküldött oktatóanyag nevét a gyűjteményből.

Kövessük az alábbi lépéseket az első RESTful webszolgáltatásunk létrehozásához, amely végrehajtja a fenti implementációt.

Az első pihentető webszolgáltatás létrehozása

Step 1) Hozzon létre egy új projektet.
Az első lépés egy üres létrehozása Asp.Net webes alkalmazás. A Visual Studio 2013-ban kattintson a Fájl->Új projekt menüpontra.

Miután az Új projekt lehetőségre kattintott, a Visual Studio egy újabb párbeszédpanelt jelenít meg, ahol kiválaszthatja a projekt típusát és megadhatja a szükséges adatokat. Ezt a következő lépésben ismertetjük.

Step 2) Adja meg a projekt nevét és helyét.

1. Győződjön meg arról, hogy először a C# Az ASP.NET webes alkalmazás websablonja. A projektnek ilyen típusúnak kell lennie ahhoz, hogy webszolgáltatás-projektet hozhasson létre. Ennek a lehetőségnek a kiválasztásával a Visual Studio elvégzi a szükséges lépéseket a webes alkalmazásokhoz szükséges fájlok hozzáadásához.
2. Adj nevet a projektednek, ami esetünkben „Webservice.REST”.
3. Ezután győződjön meg arról, hogy megadta a projektfájlok tárolási helyét.

Ha kész, a létrehozott projektfájl a Visual Studio 2013 megoldáskezelőjében jelenik meg.

Step 3) Hozza létre a webszolgáltatási fájlt.
A következő lépés a webszolgáltatásfájl létrehozása, amely a RESTful webszolgáltatást fogja tárolni.

1. Először kattintson jobb gombbal a projektfájlra az alábbiak szerint.

2. Ebben a lépésben a
   1. Kattintson a jobb gombbal a projektfájlra.
   2. Válassza a „Hozzáadás -> Új elem” lehetőséget.

A megjelenő párbeszédpanelen a következőket kell tennie.

1. Válassza a WCF szolgáltatás (Ajax-kompatibilis) lehetőséget. Az ilyen típusú fájl kiválasztása azt eredményezi, hogy a Visual Studio hozzáad néhány alapvető kódot, amely segít RESTful webszolgáltatás létrehozásában. A WCF a „WCF szolgáltatás” rövidítése. Windows Kommunikáció FoundationA WCF egy könyvtár, amely különböző platformokon (vagy ugyanazon platformon) futó alkalmazások számára készült, hogy különböző protokollokon, például TCP-n, HTTP-n és HTTPS-en keresztül kommunikáljanak. Az Ajax aszinkron. JavaForgatókönyv és XML. Az AJAX lehetővé teszi a weboldalak aszinkron frissítését kis mennyiségű adatcserével a színfalak mögötti szerverrel.
2. Ezután adjon nevet a szolgáltatásnak, ami esetünkben TutorialService.
3. Végül kattintson a Hozzáadás gombra a szolgáltatás hozzáadásához a megoldáshoz.

Step 4) Készítsen konfigurációt.
A következő lépés egy konfigurációs módosítás végrehajtása, amely lehetővé teszi a projekt működését a RESTful webszolgáltatásokkal. Ehhez módosítani kell a következő fájlt: Web.configEz a fájl ugyanabban az ablakban jelenik meg, mint a webszolgáltatás projektfájlja. A Web.config fájl tartalmazza az összes olyan konfigurációt, amely biztosítja a webalkalmazás megfelelő működését. A módosítás 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.

2. Keresd meg a vonalat .

3. Változtasd meg a sort erre: .

Step 5) Adja hozzá kódunkat a megvalósításhoz.
A következő lépés a kód hozzáadása a megvalósításhoz. Az alábbi összes kódot a TutorialService.svc fájlba kell írni.

1. Az első lépés az adatainkat reprezentáló kód hozzáadása, amelyeket a programunkban fogunk használni. Tehát lesz egy karakterlánc-változók listája „Tömbök”, „Várólisták” és „Vermek” értékekkel. Ez fogja képviselni a webes tárhelyszolgáltatásunkon keresztül elérhető oktatóanyagok neveit.

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

Step 6) Határozza meg a GET metódusunk kódját.
Következő lépésként definiáljuk a GET metódusunk kódját. Ez a kód szintén ugyanabban a TutorialService.svc fájlban fog települni. Ez a kód minden alkalommal lefut, amikor a böngészőnkből meghívjuk a szolgáltatást.

Az alábbi módszert fogjuk használni az alábbi forgatókönyv megvalósításához.

• Ha egy felhasználó az összes elérhető oktatóanyag listáját szeretné megtekinteni, akkor az alábbi kódot kell megírnia ehhez.

[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 Magyarázat:-

1. A kód első sora a legfontosabb. Ez definiálja, hogyan hívhatjuk meg ezt a metódust egy URLTehát, ha a webszolgáltatásunkra mutató link http://localhost:52645/TutorialService.svc és hozzáfűzzük a '/Tutorial'-t a következőhöz: URL, mint a http://localhost:52645/TutorialService.svc/Tutorial, a fenti kód meghívásra kerül. A „WebGet” attribútum egy paraméter, amely lehetővé teszi, hogy ez a metódus RESTful metódus legyen, így a GET művelettel meghívható.
2. Ez a kódrészlet arra szolgál, hogy végignézzük az 'lst' változóban található karakterláncok listáját, és visszaküldjük mindegyiket a hívó programnak.

Step 7) Adja vissza a kimenetet.
Az alábbi kód biztosítja, hogy ha egy GET hívást kezdeményezünk a Tutorial szolgáltatáshoz egy Tutorial azonosítóval, akkor az a Tutorial azonosító alapján adja vissza a megfelelő oktatóanyag nevét.

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

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

Code Magyarázat:-

1. A kód első sora a legfontosabb. Ez határozza meg, hogyan hívhatjuk meg ezt a metódust egy URLTehát, ha a webszolgáltatásunkra mutató link http://localhost:52645/TutorialService.svc és hozzáfűzzük a következőt: '/Tutorial/{Tutorialid} URL, meghívhatnánk a webszolgáltatást a következőképpen http://localhost:52645/TutorialService.svc/Tutorial/1, például. A webszolgáltatás ezután visszaadja az oktatóanyag nevét, amelynek az oktatóanyag azonosítója 1.
2. A kód ezen szakasza a webes metódusnak átadott oktatóanyag azonosítóját tartalmazó oktatóanyag nevének visszaadására szolgál.

• Alapértelmezés szerint arra kell emlékezni, hogy bármi is kerül átadásra a URL a böngészőben egy karakterlánc.
• De ne feledd, hogy a listánk indexének egész számnak kell lennie, ezért először adjuk hozzá a szükséges kódot, hogy a Tutorialid-t egész számmá alakítsuk.
• Ezután felhasználjuk a listánk indexpozíciójának eléréséhez, és ennek megfelelően visszaadjuk az értéket a hívó programnak.

Step 8) Írd meg a POST metódus kódját.
A következő lépés a POST metódusunk kódjának megírása. Ezt a metódust akkor hívjuk meg, amikor egy karakterlánc értéket szeretnénk hozzáadni az oktatóanyagok listájához a POST metódus segítségével. Például, ha a „Szoftvertesztelés” oktatóanyag nevét szeretnéd hozzáadni, akkor a POST metódust kell használnod.

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

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

Code Magyarázat:-

1. Az első sor a „WebInvoke” attribútum, amelyet a metódusunkhoz csatoltunk. Ez lehetővé teszi a metódus meghívását POST híváson keresztül. A RequestFormat és ResponseFormat attribútumokat JSON formátumban kell megadni, mivel amikor értékeket küldünk egy RESTFul webszolgáltatásnak, az értékeknek ebben a formátumban kell lenniük.
2. A kód második sorát arra használjuk, hogy a POST híváson keresztül átadott karakterlánc értéket hozzáadjuk a meglévő oktatóanyag karakterláncainak listájához.

Step 9) Adjon hozzá egy metódust a DELETE művelet kezeléséhez.
Végül hozzáadjuk a DELETE műveletet kezelő metódusunkat. Ezt a metódust akkor hívjuk meg, amikor egy meglévő karakterláncot szeretnénk törölni a tutoriálok listájából a DELETE metódus segítségével.

[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 Magyarázat:-

1. Az első sor a „WebInvoke” attribútum, amelyet a metódusunkhoz csatoltunk. Ez lehetővé teszi a metódus meghívását a DELETE híváson keresztül. A RequestFormat és a ResponseFormat attribútumokat JSON-ként kell megadni, mivel az értékeknek ebben a formátumban kell lenniük. Fontos megjegyezni, hogy a Method paraméter „DELETE” értékre van állítva. Ez azt jelenti, hogy valahányszor kiadjuk a DELETE műveletet, ez a metódus kerül meghívásra.
2. A második kódsor a DELETE hívással küldött Tutorialid felvételére szolgál, majd ezt követően törli az azonosítót a listánkból. (A Int32 A kódban található függvény a Tutorial azonosítóját karakterláncváltozóból egész számmá alakítja.)

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

Most, hogy létrehoztuk a teljes webszolgáltatásunkat a fenti szakaszban, nézzük meg, hogyan futtathatjuk a Tutorial szolgáltatást úgy, hogy az bármely kliensről meghívható legyen.

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

Step 1) Kattintson a jobb gombbal a projektfájlra – Webservice.REST.

Step 2) Válassza a „Beállítás indítási projektként” menüpontot. Ez biztosítja, hogy ez a projekt is fusson, amikor a Visual Studio futtatja a teljes megoldást.

Step 3) A következő lépés maga a projekt futtatása. A rendszerre telepített alapértelmezett böngészőtől függően a megfelelő böngésző neve megjelenik a futtatás gomb mellett a Visual Studio-ban. Esetünkben a következő van: Google Chrome felbukkan. Csak kattintson erre a gombra.

Kimenet:-

Amikor a projekt fut, böngészhetsz a TutorialService.svc/Tutorial szakaszban, és az alábbi kimenetet fogod látni.

A fenti kimenetben

• Látható, hogy a böngésző meghívja a 'GET' műveletet és végrehajtja a 'GetAllTutorial' metódust a webszolgáltatásban. Ez a modul a webszolgáltatásunk által közzétett összes oktatóanyag megjelenítésére szolgál.

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

A fenti szakaszban már láttuk, hogyan használhatjuk a böngészőt a 'GET' parancs végrehajtására és a 'GetAllTutorial' meghívására.

1. Használjuk most a böngészőt a következő használati eset forgatókönyv végrehajtásához.

GET Tutorial/Tutorialid – Amikor egy kliens meghívja ezt a Restful API-t, a kliens által küldött Tutorialid alapján megkapja a bemutató nevét.

A böngészőben fűzd hozzá a /1 karakterláncot a Tutorial szó után a URLHa megnyomja az Enter billentyűt, az alábbi kimenetet kapja.

Most a „Queues” kimenetét fogod látni, amely az oktatóanyag-sztringek listájában az 1-es számnak felel meg. Ez azt jelenti, hogy a webszolgáltatásunk most meghívja a „GetTutorialbyID” metódust. Ez azt is mutatja, hogy az 1-es érték sikeresen átadódik a böngészőn keresztül a webszolgáltatásunknak és a metódusunknak, és ezért kapjuk meg a böngészőben a „Queues” megfelelő helyes értékét.

2. Következő lépésként használjuk fel a webszolgáltatásunkat az alábbi forgatókönyv végrehajtásával. Ehhez telepítened kell a következő nevű eszközt: Fiddler, ami egy ingyenesen letölthető eszköz.

POST Tutorial/Tutorialname – Amikor egy kliens meghívja ezt a Restful API-t, a kliens egy kérést küld be egy Tutorialname beillesztésére. A webszolgáltatás ezután hozzáadja a beküldött oktatóanyag nevét a gyűjteményhez.

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

1. Lépj a zeneszerző részhez. Ezzel hozhatsz létre kéréseket, amelyeket bármilyen webes alkalmazásba beküldhetsz.
2. Győződjön meg arról, hogy a kérés típusa „POST”, és a helyes URL ütés éri, ami a mi esetünkben annak is kellene lennie http://localhost:52645/TutorialService.svc/Tutorial.
3. Győződjön meg róla, hogy a Content-Type (tartalomtípus) application/json-ként van megjelölve. Ne feledje, hogy a webszolgáltatásunkban a POST kérésmetódus csak JSON stílusú adatokat fogad el, ezért ezt meg kell adnunk, amikor kérést küldünk az alkalmazásunknak.
4. Végül meg kell adnunk az adatainkat. Ne feledjük, hogy a POST metódusunk elfogad egy 'str' nevű paramétert. Tehát itt azt adjuk meg, hogy egy „Fák” nevű értéket szeretnénk hozzáadni az oktatóanyag-nevek gyűjteményéhez, és biztosítjuk, hogy az 'str' változónévhez legyen címkézve.

Végül kattintson a Végrehajtás gombra a FiddlerEz egy kérést küld a webszolgáltatásnak, hogy POST küldje el a „Fák” adatot a webszolgáltatásunknak.

Most, amikor a Tutorialhoz böngészünk URL Az oktatóanyag listájában szereplő összes karakterlánc megjelenítéséhez látni fogja, hogy a „Trees” érték is jelen van. Ez azt mutatja, hogy a webszolgáltatáshoz intézett POST kérés sikeresen végrehajtódott, és hogy a szolgáltatás sikeresen hozzáadódott az oktatóanyag listájához.

3. Következő lépésként használjuk fel webszolgáltatásunkat az alábbi forgatókönyv végrehajtásával. Ehhez a következőt is használnunk kell: Fiddler eszköz.

Tutorial/Tutorialid TÖRLÉSE – Amikor egy kliens meghívja ezt a Restful API-t, a kliens egy kérést küld be a Tutorialid alapján a Tutorialname törlésére. A webszolgáltatás ezután törli a beküldött oktatóanyag nevét a gyűjteményből.

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

1. Lépj a zeneszerző részhez. Ezzel hozhatsz létre kéréseket, amelyeket bármilyen webes alkalmazásba beküldhetsz.
2. Győződjön meg arról, hogy a kérés típusa „TÖRLÉS” és a helyes URL ütés éri, ami a mi esetünkben annak is kellene lennie http://localhost:52645/TutorialService.svc/TutorialGyőződjön meg arról, hogy a listában lévő karakterlánc törléséhez használt azonosító a következőn keresztül kerül elküldésre: URL paraméterként. A REST példánkban 1-et küldünk, tehát ez törli a 2-t^nd elem a gyűjteményünkben, ami a „Várólisták”.

Végül kattintson a Végrehajtás gombra a FiddlerEz egy kérést küld a webszolgáltatásnak, hogy TÖRLJE az adatsorokat a webszolgáltatásunkból.

Most, amikor a Tutorialhoz böngészünk URL Az oktatóanyag listájában szereplő összes karakterlánc megjelenítéséhez észre fogja venni, hogy a „Várólisták” értéke már nem szerepel.

Ez azt mutatja, hogy a webszolgáltatásnak küldött DELETE kérés sikeresen végrehajtódott. Az oktatóanyag sztringjeinek listájában az 1. indexszámú elem sikeresen törölve lett.

RESTful API ajánlott gyakorlatok

Egy működőképes REST API létrehozása csak az első lépés; egy skálázható és karbantartható API létrehozása fegyelmet igényel. Az alábbi gyakorlatok segítenek abban, hogy a végpontok kiszámíthatóak, biztonságosak és könnyen használhatóak legyenek más fejlesztők és MI-ügynökök számára.

• Főneveket használj, ne igéket URLs. Végpontok, mint például /alkalmazottak/1 világosabbak, mint /getEmployee?id=1, mivel a HTTP ige már leírja a műveletet.
• Értelmes állapotkódokat ad vissza. 200-as kódot küldjön sikeres kérés esetén, 201-et létrehozott erőforrás esetén, 400-at hibás kérés esetén, 401-et jogosulatlan hozzáférés esetén, 404-et hiányzó erőforrás esetén és 500-at szerverhibák esetén.
• Verziózza az API-ját. Verziószegmens hozzáadása, például /v1/ az elérési úton lehetővé teszi a szolgáltatás fejlesztését a meglévő ügyfelek megszakítása nélkül.
• Biztosítson minden végpontot. Használjon HTTPS-t API-kulcsokkal vagy OAuth 2.0 tokenekkel együtt, és ellenőrizze az összes bejövő bemenetet.
• Támogassa a lapozást és a szűrést. A nagy gyűjtemények oldalakon való visszaadása gyors válaszokat biztosít és csökkenti a szerver terhelését.

Ezen konvenciók betartásával a RESTful webszolgáltatásod intuitív módon integrálható, függetlenül attól, hogy a felhasználó egy mobilalkalmazás, egy partnerrendszer vagy egy automatizált mesterséges intelligencia által létrehozott munkafolyamat.

GYIK