Az API Server minden API-kérést elfogad külső alkalmazásoktól. A felhasználók hitelesítésére az API Server a nyilvános kulcsú titkosításhoz hasonló hitelesítési rendszert használ.

Nyilvános kulcsú kriptográfiai rendszer (vagy aszimmetrikus titkosítás, aszimmetrikus titkosítás) - titkosítási és/vagy elektronikus rendszer digitális aláírás(EDS), amelyben nyilvános kulcs nyílt (azaz nem védett, megfigyelésre hozzáférhető) csatornán továbbítják, és a digitális aláírás ellenőrzésére és az üzenet titkosítására használják. EDS generálásához és üzenet visszafejtéséhez használják A titkos kulcs.

Az API-kiszolgálóhoz intézett összes kérés az elülső vezérlőfájlba kerül. Ebben a fájlban azonosítható a nyilvános és a privát kulcs.

Itt lépésről lépésre leírás ez a folyamat:

• Az API-kliens kérése érkezik a kiszolgálóhoz az elülső vezérlőfájl helyén. A kérelem tartalmazza az APP ID-t (az ügyfél nyilvános kulcsát) és az APP KEY-t (a kliens privát kulcsával titkosított 32 karakteres karakterláncot). A titkos kulcs soha nem kerül elküldésre a szervernek, csak a kérés titkosítására szolgál. A kérés tartalmazza a szerverhívás paramétereit - felhasználó, hozzáférési jelszó, vezérlő neve és művelet, amely feldolgozza az ügyfélhívást. Például egy sor opció így nézhet ki:

$items = array("vezérlő" => "teendő", "művelet" => "olvasás", "felhasználónév" => $felhasználónév, "userpass" => $felhasználói jelszó);

• Amikor egy kérés érkezik az API-kiszolgálóhoz, a szerver ellenőrzi az alkalmazások listáját, hogy van-e nyilvános kulcs (APP ID);
• Ha a nyilvános kulcs nem található, a „Kérés” típusú kivétel nem érvényes". Ha a kulcs megvan, a szerver veszi a titkos kulcsot, amely megfelel ennek a nyilvános kulcsnak, és megpróbálja visszafejteni a bejövő kérést;
• Ha a visszafejtés sikeres volt, a vezérlőt és a műveleti paramétereket a rendszer lekéri a bejövő kérésből, és feldolgozza. A kérést kezelő elülső vezérlő csatlakozik kívánt fájlt vezérlőt, és meghívja az akcióparaméterben található műveletet;
• A kérés feldolgozása sikeres/sikertelen feldolgozása esetén a kliens választ kap az API szervertől.

Vladimir, a Noveo webfejlesztője mondja

A weboldalak, webszolgáltatások és mobilalkalmazások legtöbb fejlesztőjének előbb-utóbb meg kell küzdenie a kliens-szerver architektúrával, vagyis webes API-t kell fejlesztenie vagy integrálnia kell vele. Annak érdekében, hogy ne találjunk ki minden alkalommal valami újat, fontos egy viszonylag univerzális megközelítést kialakítani a webes API tervezésben, a hasonló rendszerek fejlesztésének tapasztalatai alapján. A témában összevont cikksorozatot ajánlunk figyelmébe.

Első megközelítés: színészek

Egy szép pillanatban, a következő webszolgáltatás létrehozása során úgy döntöttem, hogy összeszedem minden tudásomat és gondolatomat a kliens alkalmazások igényeit kielégítő webes API tervezés témájában, és egy cikk vagy egy cikksorozat. Természetesen a tapasztalataim nem állítják a feltétlenséget, az építő jellegű kritikákat és kiegészítéseket is szívesen fogadom.

Az olvasás inkább filozófiaira sikerült, mint technikaira, de a technikai rész kedvelőinek itt lesz min elgondolkodni. Kétlem, hogy valami alapvetően újat mondanék ebben a cikkben, olyat, amit még soha nem hallottál, olvastál vagy gondoltál magadról. Csak próbálok mindent beleilleszteni egységes rendszer, elsősorban a saját fejedben, és ez már nagyon sokat ér. Ennek ellenére örülök, ha kitalációim hasznosak lesznek az Ön gyakorlatában. Akkor gyerünk.

Kliens és szerver

szerver ebben az esetben egy absztrakt gépet tekintünk a hálózaton, amely képes HTTP kérést fogadni, feldolgozni és érvényes választ adni. Ennek a cikknek az összefüggésében a fizikai lényege és a belső architektúrája teljesen lényegtelen, legyen szó diák laptopról vagy a világban szétszórt ipari szerverek hatalmas klaszteréről. Ugyanígy nekünk sem mindegy, hogy mi van a motorháztető alatt, ki teljesíti a kérést az ajtóban, Apache vagy Nginx, milyen ismeretlen vadállat, PHP, Python vagy Ruby dolgozza fel és generál választ, milyen adattár használt: Postgresql, MySQL vagy MongoDB. A lényeg az, hogy a szerver megfeleljen a fő szabálynak - hallani, megérteni és megbocsátani a választ.

Ügyfél az is lehet bármi, ami HTTP-kérést képezhet és küldhet. A cikk egy bizonyos pontjáig nem fogunk különösebben érdekelni, hogy az ügyfél milyen célokat tűz ki maga elé a kérés elküldésekor, valamint az, hogy mit fog kezdeni a válasszal. A kliens lehet a böngészőben futó JavaScript szkript, mobil alkalmazás, egy gonosz (vagy nem olyan) démon fut a szerveren, vagy egy túl bölcsebb hűtőszekrény (van már ilyen).

Többnyire a fenti kettő kommunikációjának módjáról fogunk beszélni, úgy, hogy megértsék egymást, és egyiküknek se legyen kérdése.

REST filozófia

A REST (Representational State Transfer) eredetileg egy egyszerű és egyértelmű adatkezelési interfésznek készült, amely csak néhány alapvető műveletet tartalmaz közvetlen hálózati tárolással (szerverrel): adatlehívás (GET), mentés (POST), módosítás (PUT / PATCH) és törlés (DELETE). Természetesen ehhez a listához mindig is társultak olyan lehetőségek, mint a hibakezelés a kérésben (jól van-e a kérés), az adathozzáférés ellenőrzése (hirtelen ezt nem szabad tudni) és a beérkező adatok érvényesítése (hirtelen hülyeséget írtál), általános, minden lehetséges ellenőrzéseket amelyet a szerver végrehajt a kívánság teljesítése előtt ügyfél.

Ezenkívül a REST számos építészeti alapelvvel rendelkezik, amelyek listája bármely más REST cikkben megtalálható. Nézzük át őket röviden, hogy kéznél legyenek, és ne kelljen sehova menni:

Szerver függetlenség a klienstől- a szerverek és a kliensek azonnal lecserélhetők másra, egymástól függetlenül, mivel a köztük lévő interfész nem változik. A szerver nem tárolja az ügyfélállapotokat.
Az erőforráscímek egyedisége- minden adategységnek (bármilyen fokú egymásba ágyazás) megvan a maga egyedi URL-címe, amely valójában teljes egészében az erőforrás egyedi azonosítója.

Példa: Szerezze be az /api/v1/users/25/name

Az adattárolási formátum függetlensége továbbításuk formátumától- a szerver több támogatást is tud különféle formátumok ugyanazon adatok átvitelére (JSON, XML stb.), de az adatokat belső formátumában tárolja, függetlenül a támogatottaktól.

Minden szükséges metaadat megléte a válaszban- a szervernek az adatokon kívül vissza kell adnia a kérés feldolgozásának részleteit, például hibaüzeneteket, különféle erőforrás-tulajdonságokat, amelyek szükségesek további munka ezzel például a gyűjtemény bejegyzéseinek teljes számát helyes megjelenítés oldal navigáció. Áttekintjük a különböző típusú forrásokat.

Mi hiányzik nekünk

A klasszikus REST azt jelenti, hogy a kliens a szerverrel lapos adattárolóként dolgozik, miközben az adatok egymás közötti kapcsolatáról és egymásrautaltságáról nem esik szó. Mindez alapértelmezés szerint teljes mértékben az ügyfélalkalmazás vállára esik. Azok a modern szakterületek azonban, amelyekre adatkezelési rendszereket fejlesztenek, legyen szó szociális szolgáltatásokról vagy internetes marketingrendszerekről, az adatbázisban tárolt entitások közötti komplex kapcsolatot feltételeznek. Ezeknek a linkeknek a támogatása, pl. az adatok integritása a szerveroldal felelőssége, míg a kliens csak egy felület az adatok eléréséhez. Tehát mi hiányzik a REST-ből?

Funkcióhívások

Annak érdekében, hogy ne változtassuk meg az adatokat és a köztük lévő kapcsolatokat manuálisan, egyszerűen meghívunk egy függvényt az erőforráson, és „tápláljuk” a szükséges adatokat argumentumként. Ez a művelet nem felel meg a REST szabványoknak, nincs rá külön ige, ami miatt minket, fejlesztőket egyszerre kapunk ki.

A legegyszerűbb példa– felhasználói jogosultság. Meghívjuk a bejelentkezési függvényt, argumentumként átadjuk neki a hitelesítő adatokat tartalmazó objektumot, és cserébe hozzáférési kulcsot kapunk. Az, hogy mi történik a szerver oldalon lévő adatokkal, nem zavar minket.

Egy másik lehetőség- az adatok közötti kapcsolatok létrehozása és megszakítása. Például egy felhasználó hozzáadása egy csoporthoz. Egy entitás felhívása csoport addUser függvényt, adja át az objektumot paraméterként felhasználó, megkapjuk az eredményt.

És még vannak olyan műveletek, amelyek nem kapcsolódnak közvetlenül az adatok mentéséhez mint olyanokhoz, például értesítések küldése, bármely művelet megerősítése vagy elutasítása (jelentési időszak vége stb.).

Több művelet

Gyakran előfordul, és a kliensfejlesztők érteni fogják, mire gondolok, hogy egy kliens alkalmazásnak kényelmesebb egyszerre több homogén objektumot létrehozni / módosítani / törölni / egy kéréssel, és minden egyes objektum esetében lehetséges a szerveroldali ítélet. Itt legalább több lehetőség van: vagy az összes módosítást végrehajtották, vagy részben (egyes objektumoknál), vagy hiba történt. Nos, több stratégia is létezik: csak akkor alkalmazza a változtatásokat, ha mindenkinél sikeres, vagy csak részben alkalmazza, vagy bármilyen hiba esetén visszalép, és ez már egy teljes tranzakciós mechanizmust húz.

Egy ideálisra törekvő webes API-nál az ilyen műveleteket is szeretnék valahogyan bevinni a rendszerbe. Megpróbálom az egyik folytatásban.

Statisztikai lekérdezések, aggregátorok, adatformázás

Gyakran előfordul, hogy a szerveren tárolt adatok alapján statisztikai squeeze-t, vagy speciális módon formázott adatokat kell kapnunk: például a kliens oldalon történő ábrázoláshoz. Lényegében igény szerint, többé-kevésbé menet közben generált adatokról van szó, amelyek csak olvashatók, ezért érdemes külön kategóriába sorolni. Az egyik megkülönböztető jellegzetességek A statisztika véleményem szerint az, hogy nincs egyedi azonosítójuk.

Biztos vagyok benne, hogy ez nem minden, amivel valódi alkalmazások fejlesztése során találkozhat, és örülök a kiegészítéseknek és javításoknak.

Az adatok fajtái

Objektumok

A kliens és a szerver közötti kommunikáció kulcsfontosságú adattípusa egy objektum. Lényegében egy objektum a tulajdonságok és a hozzájuk tartozó értékek listája. Egy kérésben elküldhetünk egy objektumot a szervernek, és a kérés eredményét objektumként kaphatjuk meg. Ebben az esetben az objektum nem feltétlenül az adatbázisban tárolt valós entitás, legalábbis abban a formában, ahogyan küldték vagy fogadták. Például a hitelesítési adatok objektumként kerülnek átadásra, de nem független entitások. Még az adatbázisban tárolt objektumok is hajlamosak növekedni további tulajdonságok rendszeren belüli jellegűek, például dátumok létrehozása és szerkesztése, különféle rendszercímkék és zászlók. Az objektumtulajdonságok lehetnek saját skalárértékeik, vagy tartalmazhatnak kapcsolódó objektumok És tárgygyűjtemények, amelyek nem részei az objektumnak. Az objektumok tulajdonságainak egy része szerkeszthető, van, amelyik csak olvasható, más része pedig statisztikai jellegű és menet közben kiszámítható (például a lájkok száma). A felhasználó jogaitól függően egyes objektumtulajdonságok rejtettek lehetnek.

Tárgygyűjtemények

Ha gyűjteményekről beszélünk, akkor egyfajta szerver erőforrást értünk, amely lehetővé teszi, hogy homogén objektumok listájával dolgozzunk, pl. objektumokat hozzáadhat, törölhet, módosíthat és válasszon belőlük. Ráadásul a gyűjteménynek elméletileg lehetnek saját tulajdonságai (pl. oldalankénti maximális elemszám) és funkciói (itt értetlenkedem, de ez is megtörtént).

Skaláris értékek

Tiszta formájában a skaláris értékek különálló entitásként rendkívül ritkák voltak az emlékezetemben. Általában tárgyak vagy gyűjtemények tulajdonságaiként jelentek meg, és mint ilyenek, olvashatók vagy írhatók. Például a felhasználónév egyenként lekérhető és módosítható a GET /users/1/name paranccsal. A gyakorlatban ez a funkció ritkán hasznos, de ha szükséges, szeretném, ha kéznél lenne. Ez különösen igaz a gyűjteménytulajdonságokra, mint például a rekordok száma (szűréssel vagy anélkül): GET /news/count .

A következő cikkek egyikében megpróbálom ezeket a műveleteket osztályozni, és lehetőségeket kínálni az esetleges kérésekre, válaszokra, amelyek alapján a gyakorlatban találkoztam.

Második megközelítés: a helyes út

Ebben a közelítésben külön szeretnék beszélni a webes API erőforrásaihoz és módszereihez vezető egyedi útvonalak létrehozásának megközelítéseiről, valamint az alkalmazás azon architekturális jellemzőiről, amelyek hatással vannak. kinézet ezt az utat és összetevőit.

Mire kell gondolni, ha a tengerparton állsz

Verziószámítás

Előbb-utóbb minden operációs rendszer fejlődni kezd: fejlődni, összetettebbé válik, méreteződik, modernizálódik. A REST API fejlesztők számára ez elsősorban azzal jár, hogy a régiek működése közben szükséges az API új verzióinak elindítása. Itt most nem a rendszer burkolata alatti architekturális változásokról beszélek, hanem arról, hogy maga az adatformátum és a velük végzett műveletek halmaza változik. Mindenesetre biztosítani kell a verziószámítást mind a forráskód kezdeti felépítésében, mind az URL-ek felépítésének elvében. Ami az URL-t illeti, két legnépszerűbb módszer létezik az API verziójának megadására, amelyre a kérelem vonatkozik. Az example-api.com/v1/ elérési út előtagja és verziószámítás a v1.example-api.com aldomain szintjén. Igénytől és igénytől függően bármelyiket használhatja.

Komponens autonómia

A több felhasználói szerepkört támogató összetett rendszerek webes API-ját gyakran részekre kell osztani, amelyek mindegyike más-más feladatkört szolgál ki. Valójában mindegyik rész lehet egy független alkalmazás, amely különböző fizikai gépeken és platformokon fut. Az API leírása kapcsán számunkra egyáltalán nem mindegy, hogy a szerver hogyan dolgozza fel a kérést, és ebben milyen erők, technológiák vesznek részt. Az API kliens esetében a rendszer be van zárva. A rendszer különböző részei azonban teljesen eltérő funkciókkal rendelkezhetnek, például az adminisztratív és a felhasználói részek. És úgy tűnik, hogy az ugyanazokkal való munka módszertana jelentősen eltérhet egymástól. Ezért az ilyen részeket az admin.v1.example-api.com tartomány vagy az example-api.com/v1/admin/ elérési út előtag szintjén kell elválasztani. Ez a követelmény nem kötelező, és sok függ a rendszer összetettségétől és céljától.

Adatcsere formátum

Véleményem szerint a legkényelmesebb és legfunkcionálisabb adatcsere formátum a JSON, de senki sem tiltja az XML, YAML vagy bármilyen más formátum használatát, amely lehetővé teszi a szerializált objektumok tárolását az adattípus elvesztése nélkül. Ha szükséges, több bemeneti / kimeneti formátumot is támogathat az API-ban. Elegendő a HTTP kérés fejlécet használni a kívánt válaszformátum Accept és Content-Type jelzésére a kérésben átadott adatok formátumának jelzésére. Egy másik népszerű módszer, ha bővítményt adunk az erőforrás URL-jéhez, például GET /users.xml , de ez a módszer kevésbé tűnik rugalmasnak és szépnek, már csak azért is, mert nehezebbé teszi az URL-t, és jobban igaz a GET kérésekre, mint az összesre. lehetséges műveletek.

Lokalizáció és többnyelvűség

A gyakorlatban az API többnyelvűsége leggyakrabban a szolgáltatás- és hibaüzenetek megfelelő nyelvre történő lefordításán múlik, hogy közvetlenül a végfelhasználó számára megjelenjenek. A többnyelvű tartalomnak is megvan a helye, de a tartalom különböző nyelveken történő mentését és kiadását véleményem szerint világosabban meg kell különböztetni, például ha ugyanaz a cikk van különböző nyelveken, akkor valójában két különböző entitásról van szó. a tartalom egységének jelével. A várt nyelv azonosításához használhatja különböző utak. A legegyszerűbb a szabványos HTTP-fejléc Accept-Language . Láttam más módokat is, mint például a language="en" GET paraméter hozzáadása, az example-api.com/en/ elérési út előtag használatával, vagy akár az en.example-api.com domain név szintjén. Számomra úgy tűnik, hogy a területi beállítás megadásának módja az adott alkalmazástól és az előtte álló feladatoktól függ.

Belső útválasztás

Tehát eljutottunk API-nk gyökércsomópontjához (vagy annak egyik összetevőjéhez). Minden további útvonal közvetlenül a szerveralkalmazáson belül halad át, az általa támogatott erőforráskészletnek megfelelően.

Gyűjtési útvonalak

A gyűjtemény elérési útjának megadásához egyszerűen a megfelelő entitás nevét használjuk, például ha ez a felhasználók listája, akkor az elérési út /users lesz. Egy gyűjteményre önmagában két módszer alkalmazható: GET (korlátozott entitáslista lekérése) és POST (új elem létrehozása). Nagyon sok további GET paramétert használhatunk a listák lekérésére irányuló kérésekben, lapozásra, rendezésre, szűrésre, keresésre stb., de ezeknek opcionálisnak kell lenniük, pl. ezeket a paramétereket nem szabad az elérési út részeként átadni!

Gyűjtemény elemei

A gyűjtemény egy adott elemére való hivatkozáshoz a /users/25 egyedi azonosítóját használjuk az útvonalban. Ez az egyedülálló út hozzá. Az objektumokkal való munkavégzéshez a GET (objektum beszerzése), PUT / PATCH (módosítás) és DELETE (törlés) módszerek alkalmazhatók.

Egyedi tárgyak

Sok szolgáltatás rendelkezik az aktuális felhasználó egyedi objektumaival, például az aktuális felhasználó profiljával /profile vagy személyes beállításokkal / beállításokkal. Természetesen ezek egyrészt az egyik gyűjtemény elemei, de ezek a kiindulópontok a webes API-nknak a kliens alkalmazás általi használatához, emellett sokkal többet tesznek lehetővé. széleskörű adatokkal végzett műveletek. Ugyanakkor előfordulhat, hogy a felhasználói beállításokat tároló gyűjtemény biztonsági és adatvédelmi okokból egyáltalán nem érhető el.

Tárgyak és gyűjtemények tulajdonságai

Ahhoz, hogy egy objektum bármely tulajdonságához közvetlenül hozzáférjünk, elegendő a tulajdonság nevét hozzáadni az objektum elérési útjához, például megkapjuk a /users/25/name felhasználónevet. A tulajdonságra a GET (érték beszerzése) és a PUT/PATCH (értékváltozás) módszerek alkalmazhatók. A DELETE módszer nem alkalmazható, mert a tulajdonság egy objektum szerkezeti része, mint formalizált adategység.

Az előző részben arról volt szó, hogy a gyűjteményeknek, akárcsak az objektumoknak, lehetnek saját tulajdonságaik. Emlékeim szerint csak a count tulajdonság volt hasznos számomra, de az Ön alkalmazása összetettebb és specifikusabb lehet. A gyűjtemény tulajdonságaihoz vezető útvonalak ugyanazon elv szerint épülnek fel, mint az elemeik tulajdonságai: /users/count . Gyűjteménytulajdonoknál csak a GET módszer (tulajdon beszerzése) alkalmazható. a gyűjtemény csak egy felület a lista eléréséhez.

Kapcsolódó objektumok gyűjteményei

Az objektumtulajdonságok egy fajtája lehetnek kapcsolódó objektumok vagy kapcsolódó objektumok gyűjteményei. Az ilyen entitások általában nem az objektum saját tulajdonát képezik, hanem csak hivatkozások más entitásokkal való kapcsolataira. Például a /users/25/roles felhasználóhoz rendelt szerepkörök listája. A beágyazott objektumokkal és gyűjteményekkel való munkavégzésről a következő részek egyikében fogunk részletesen beszélni, de ebben a szakaszban már elegendő, ha közvetlenül hozzáférünk hozzájuk, mint egy objektum bármely más tulajdonságához.

Objektum és gyűjtemény funkciók

Egy gyűjtemény vagy objektum függvényhívási felületének elérési útjának létrehozásához ugyanazt a megközelítést alkalmazzuk, mint egy tulajdonság eléréséhez. Például a /users/25/sendPasswordReminder objektumhoz vagy a /users/disableUnconfirmed gyűjteményhez. Függvényhívásoknál egyébként is a POST metódust használjuk. Miért? Hadd emlékeztesselek arra, hogy a klasszikus REST-ben nincs speciális ige a függvények hívására, ezért a meglévők egyikét kell használnunk. Véleményem szerint erre a POST módszer a legalkalmasabb. lehetővé teszi a szükséges argumentumok átadását a szervernek, nem idempotens (többszöri elérésre ugyanazt az eredményt adja vissza), és a szemantikában a legabsztraktabb.

Remélem, többé-kevésbé minden belefért a rendszerbe 🙂 A következő részben a kérésekről és válaszokról, azok formátumairól, állapotkódjairól lesz szó részletesebben.

Harmadik megközelítés: kérések és válaszok

Az előző közelítésekben beszéltem arról, hogyan jött az ötlet a meglévő tapasztalatok összegyűjtésére és általánosítására webfejlesztés API. Az első részben megpróbáltam leírni, hogy a webes API tervezése során milyen típusú erőforrásokkal és az azokon végzett műveletekkel van dolgunk. A második rész az ezekhez az erőforrásokhoz való hozzáféréshez szükséges egyedi URL-ek létrehozásának problémáit érintette. És ebben a közelítésben megpróbálom leírni lehetséges opciók kéréseket és válaszokat.

Univerzális válasz

Korábban már említettük, hogy a szerver és a kliens közötti kommunikáció konkrét formátuma tetszőleges lehet, a fejlesztő belátása szerint. Számomra a legkényelmesebbnek és leglátványosabbnak tűnik JSON formátum, bár egy valódi alkalmazás több formátumot is támogathat. Egyelőre koncentráljunk a válaszobjektum szerkezetére és kötelező attribútumaira. Igen, a szerver által visszaküldött összes adatot egy speciális tárolóba csomagoljuk - általános válaszobjektum, amely minden szükséges szolgáltatási információt tartalmazni fog a további feldolgozásához. Tehát mi ez az információ:

Siker - a kérés sikerességének jelzője

Ahhoz, hogy azonnal megértsük, hogy a kérés sikeres volt-e, amikor a szervertől választ kaptunk, és átadjuk a megfelelő kezelőnek, elegendő a „siker” sikerjelzőt használni. A legegyszerűbb, adatokat nem tartalmazó szerverválasz így néz ki:

POST /api/v1/articles/22/publish ( "siker": igaz )

Hiba – információ a hibáról

Ha a kérés sikertelen – a negatív szerverválaszok okairól és típusairól kicsit később lesz szó – a válaszhoz hozzáadódik az "error" attribútum, amely tartalmazza a HTTP állapotkódot és a hibaüzenet szövegét. Kérjük, ne keverje össze az üzenetekkel érvényesítési hibák adott mezők adatait. Véleményem szerint a leghelyesebb az állapotkód visszaadása a válaszfejlécben, de találkoztam egy másik megközelítéssel is - mindig a 200-as állapotot (siker) adja vissza a fejlécben, és küldje el a részleteket és az esetleges hibaadatokat a válasz törzsében.

GET /api/v1/user ( "siker": hamis, "hiba": ( "kód" : 401, "üzenet" : "Az engedélyezés nem sikerült" ) )

Adatok – a szerver által visszaküldött adatok

A legtöbb szerver válasz adatvisszaadásra készült. A kérés típusától és sikerességétől függően az elvárt adatsor eltérő lesz, azonban a válaszok túlnyomó többségében jelen lesz az "adat" attribútum.

Példa a sikeresen visszaküldött adatokra. Ebben az esetben a válasz tartalmazza a kért felhasználói objektumot.

GET /api/v1/user ( "siker": igaz, "adat": ( "id" : 125, "e-mail" : "[email protected]", "name" : "János", "vezetéknév" : "Kovács", ) )

Példa hiba esetén visszaadott adatokra. Ebben az esetben mezőneveket és érvényesítési hibaüzeneteket tartalmaz.

PUT /api/v1/user ( "siker": hamis, "hiba": ( "kód" : 422, "üzenet" : "Az ellenőrzés sikertelen" ) "data": ( "e-mail" : "Az e-mail mező nem lehet üres. ", ) )

Lapozás - az oldalszámozás megszervezéséhez szükséges információk

A tényleges adatokon túl a visszaküldött válaszokban gyűjtemény elemek beállítása, a lekérdezés eredménye alapján információnak kell lennie a lapozásról.

Az oldalszámozás minimális értékkészlete a következőkből áll:

• rekordok teljes száma;
• oldalszám;
• aktuális oldalszám;
• rekordok száma oldalanként;
• a szerveroldal által támogatott oldalankénti rekordok maximális száma.

Egyes webes API-fejlesztők kész hivatkozásokat is tartalmaznak a szomszédos oldalakra, valamint az első, utolsó és aktuális oldalakra az oldalszámozásban.

GET /api/v1/articles Válasz: ( "siker": igaz, "adat": [ ( "id" : 1, "title" : "Érdekes dolog", ), ( "id" : 2, "title" : "Unalmas szöveg", ) ], "oldalszámozás": ( "totalRecords" : 2, "totalPages" : 1, "currentPage" : 1, "perPage" : 20, "maxPerPage" : 100, ) )

Dolgozz a hibákon

Ahogy fentebb említettük, nem minden webes API-ra irányuló kérés sikeres, de ez is a játék része. A hibabejelentő rendszer egy hatékony eszköz, amely megkönnyíti az ügyfél munkáját, és a megfelelő úton irányítja az ügyfélalkalmazást. A „hiba” szó ebben az összefüggésben nem teljesen helyénvaló. Ide jobban illik a szó. kivétel, mivel valójában a kérés sikeresen érkezett, elemzett, és megfelelő választ küldenek rá, megmagyarázva, miért nem teljesíthető a kérés.

Melyek az Ön által kapott kivételek lehetséges okai?

500 Belső szerverhiba - minden elromlott, de hamarosan kijavítjuk

Pontosan ez az eset áll fenn, ha magán a szerver oldalán jelentkezett a probléma, és a kliens alkalmazás csak sóhajtva értesíti a felhasználót, hogy a szerver elfáradt, és lefeküdt pihenni. Például megszakadt a kapcsolat az adatbázissal, vagy hiba van a kódban.

400 Rossz kérés - és most minden elromlott

A válasz pont az ellenkezője az előzőnek. Akkor jelenik meg, amikor az ügyfélalkalmazás olyan kérést küld, amely elvileg nem dolgozható fel megfelelően, nem tartalmazza a szükséges paramétereket, vagy szintaktikai hibákat tartalmaz. Ez általában a webes API dokumentációjának újraolvasásával javítható.

401 Jogosulatlan – idegen, azonosítsa magát

Az erőforrás eléréséhez engedély szükséges. Természetesen a jogosultság megléte nem garantálja, hogy az erőforrás elérhetővé válik, de felhatalmazás nélkül nem fog tudni biztosan. Ez akkor fordul elő, amikor például az API privát részéhez próbál hozzáférni, vagy amikor az aktuális token lejár.

403 Tilos – ide nem jöhetsz

A kért erőforrás létezik, de a felhasználónak nincs elegendő jogosultsága a megtekintéséhez vagy módosításához.

404 Nem található – senki sem lakik ezen a címen

Az ilyen válasz általában három esetben érkezik vissza: az erőforrás elérési útja hibás (hibás), a kért erőforrást törölték és megszűnt létezni, az aktuális felhasználó jogai nem teszik lehetővé, hogy tudjon a létezéséről a kért erőforrásból. Például a termékek listájának böngészése közben az egyik hirtelen kiment a divatból, és eltávolították.

405 A módszer nem engedélyezett

Ez a fajta kivétel közvetlenül kapcsolódik a kérésben használt igéhez (GET, PUT, POST, DELETE), amely viszont azt a műveletet jelzi, amelyet az erőforrással próbálunk végrehajtani. Ha a kért erőforrás nem támogatja a megadott műveletet, a kiszolgáló ezt közvetlenül mondja.

422 Feldolgozhatatlan entitás – javítsd ki és küldd el újra

Az egyik leghasznosabb kivétel. Visszaküldik, ha logikai hibák vannak a kérés adataiban. Kérési adatok alatt vagy a GET metódus által átadott paraméterek és a hozzájuk tartozó értékek halmazát, vagy a POST, PUT és DELETE metódusok által a kérés törzsében átadott objektum mezőit értjük. Ha az adatok nem érvényesülnek, a szerver az „adatok” részben jelentést ad vissza arról, hogy mely paraméterek érvénytelenek és miért.

A HTTP protokoll sokat támogat több különböző állapotkódok minden alkalomra, de a gyakorlatban ritkán használják őket, és a webes API kontextusában nincs gyakorlati hasznuk. Emlékeim szerint nem kellett túllépnem a fenti kivétellistán.

Kérések

Gyűjtemény elemeinek beszerzése

Az egyik leggyakoribb kérés egy gyűjtemény elemeinek beszerzésére irányuló kérés. Információs hírcsatornákat, terméklistákat, különféle információs és statisztikai táblázatokat és még sok mást jelenít meg a kliens alkalmazás a gyűjtési erőforrások elérésével. A kérés végrehajtásához a GET metódussal érjük el a gyűjteményt, és további paramétereket adunk át a lekérdezési karakterláncban. Ahogyan azt fentebb jeleztük, válaszként a gyűjtemény homogén elemeinek tömbjét és a lapozáshoz - a lista folytatásának vagy az adott oldalának betöltéséhez - szükséges információkat várjuk. A válogatás tartalma speciális módon korlátozható és passzolással rendezhető további beállítások. A továbbiakban szó lesz róluk.

Lapszámozás

oldalon- paraméter azt jelzi, hogy melyik oldalt kell megjeleníteni. Ha ezt a paramétert nem adja át, akkor az első oldal jelenik meg. Az első sikeres szerverválasztól kezdve egyértelmű lesz, hogy a gyűjtemény hány oldala van az aktuális szűrési paraméterekkel. Ha az érték meghaladja a maximális oldalszámot, akkor a legésszerűbb hibát jelezni 404 nem található.

SZEREZZE BE /api/v1/news?page=1

oldalanként- jelzi az oldalankénti kívánt elemek számát. Az API-nak általában saját alapértelmezett értéke van, amely visszaadja a perPage mezőt az oldalszámozási szakaszban, de bizonyos esetekben lehetővé teszi ennek az értéknek ésszerű határokig történő növelését a maximális maxPerPage érték megadásával:

SZEREZZE BE /api/v1/news?perPage=100

Eredmények rendezése

A kijelölés eredményeit gyakran növekvő vagy csökkenő sorrendbe kell rendezni bizonyos mezők értékei alapján, amelyek támogatják az összehasonlító (numerikus mezők esetén) vagy alfabetikus (karakterlánc mezők esetén) rendezést. Például a felhasználók listáját név szerint, vagy a termékeket ár szerint kell rendeznünk. Ezen kívül beállíthatjuk a rendezési irányt A-tól Z-ig, vagy ellenkező irányba, és a különböző mezőkhöz eltérőt.

Sorrend- Számos megközelítés létezik a GET paraméterek összetett rendezési adatainak átadására. Itt egyértelműen meg kell adni a rendezési sorrendet és irányt.

Egyes API-k ezt karakterláncként javasolják:

SZEREZZE BE /api/v1/products?sortBy=name.desc,price.asc

Más lehetőségek tömb használatát javasolják:

SZEREZZE MEG a /api/v1/products-t? sortBy=name& sortBy=desc& sortBy=price& sortBy=növekvő

Általában mindkét lehetőség egyenértékű, mivel ugyanazokat az utasításokat továbbítják. Véleményem szerint a tömbös lehetőség sokoldalúbb, de itt, ahogy mondják, az íz és a szín ...

Egyszerű szűrés érték szerint

Ahhoz, hogy a kijelölést egy mező értéke alapján szűrjük, a legtöbb esetben elegendő a mező nevét és a szükséges értéket megadni szűrési paraméterként. Például a cikkeket szerzői azonosító alapján szeretnénk szűrni:

Szerezze be az /api/v1/articles?authorId=25

Kifinomult szűrési lehetőségek

Sok interfész bonyolultabb szűrő- és keresőrendszert igényel. Felsorolom a főbb és leggyakoribb szűrési lehetőségeket.

Szűrés felső és alsó korlátok alapján összehasonlító operátorok segítségével (nagyobb vagy egyenlő), magasabb (nagyobb), (kisebb vagy egyenlő), alacsonyabb (kisebb). Azokra a mezőkre vonatkozik, amelyek értékei rangsorolhatók.

SZEREZZE BE /api/v1/products?price=500&price=1000

Szűrés több lehetséges érték alapján a listából. Mezőkre alkalmazva, beállítva lehetséges értékek amely például egy szűrőt több állapotra korlátoz:

SZEREZZE BE /api/v1/products?status=1&status=2

Szűrés részleges karakterlánc-egyezéssel. Azokra a mezőkre vonatkozik, amelyek szöveges adatokat vagy szövegként kezelhető adatokat tartalmaznak, például termékszámokat, telefonszámokat stb.

GET /api/v1/users?name=John GET /api/v1/products?code=123

Elnevezett szűrők

Egyes esetekben, amikor bizonyos szűrőparaméter-készleteket gyakran használnak, és a rendszer valami integrált dolognak tekinti őket, különösen, ha ezek a mintavétel belső, gyakran összetett mechanikáját érintik, célszerű ezeket úgynevezett elnevezett szűrőkbe csoportosítani. Elég a kérésben átadni a szűrő nevét, és a rendszer automatikusan felépíti a kijelölést.

Szerezze be az /api/v1/products?filters=recommended

Az elnevezett szűrőknek saját paramétereik is lehetnek.

SZEREZZE BE /api/v1/products?filters=kidds

Ebben az alfejezetben megpróbáltam beszélni a legnépszerűbb lehetőségekről és a szükséges minta beszerzésének módjairól. Valószínűleg a gyakorlatában sokkal több példa és árnyalat lesz ebben a témában. Ha van hozzáfűznivalód az anyagomhoz, annak csak örülök. Időközben a poszt már szilárd léptékűre nőtt, így a következő közelítésben más típusú kéréseket elemezünk.

6.1 CheckDimensions módszer

Szintaxis:

Boolean Check Dimensions(Dimensions DimensionsList,

úszó hossz,

Kiugrási szélesség,

úszó magasság,

úszó súly,

Outstring megjegyzés)

Lehetőségek:

Paraméter neve	Bemenet kimenet	típus	Leírás
DimensionsList	bemenet	Méretek	sor összsúly termék jellemzői
Hossz	szabadnap	úszó	Csomag hossza
Szélesség	szabadnap	úszó	Csomag szélessége
Magasság	szabadnap	úszó	Csomagmagasság
Súly	szabadnap	úszó	Csomag súlya
Megjegyzés	szabadnap	úszó	Szöveges leírás túllépéskor össztömeg határértékei jellemzők

Leírás:

Az összes áru súly- és méretjellemzőinek listája átkerül a módszerhez
(DimensionsList). A számítás után a kimeneti paraméterek Length, Width, Height (hossz,
szélesség és magasság) megoldása után a csomag méreteivel kell kitölteni
probléma az "optimális halmozás", és a Súly paraméter átadásra kerül az összes összsúlya
áruk, a csomagolóanyagok kivételével. Abban az esetben, ha a szállítmány méretei
túllépi a határértékeket, akkor szöveges leírás kerül átadásra a Megjegyzés paraméterhez
következetlenségek.

Visszatérési érték: A metódus logikai értéket ad vissza True if
a teljes tömeg jellemzői nem haladják meg a határértékeket és a szállítást
legalább egy lehetséges hozzáférhető módon, egyébként False. Feltehetően adott
a módszer ügyféloldalon is használható online értékeléshez
a megrendelés elküldésének alapvető lehetősége és bármely időben történő elfogadása
döntéseket, ha ez nem lehetséges.

6.1.1 Példa a CheckDimensions metódus meghívására

// Tegyük fel, hogy 2 pozíció van a kosárban, és ellenőriznie kell, hogy meghaladja-e
a megengedett méretekre és tömegre vonatkozó korlátozások
aplix.Dimensions Dimensions = új aplix.Dimensions;
aplix.DimensionsItem;

Item.Length = 0,130f;
Item.Width = 0,100f;
Item.Height = 0,001f;
Tétel.Súly = 0,1f;
Tétel.Menny. = 2;
Méretek = cikk;
Item = new aplix.Dimensions();
Item.Length = 0,1331f;
Item.Width = 0,0998f;
Tétel.Magasság = 0,0788f;
Tétel.Súly = 0,575 f;
Tétel.Menny. = 1;
Méretek = cikk;
// Kimeneti paraméterek
úszó Hossz;
úszó szélesség;
úszó Magasság;
úszó Súly;
string Megjegyzés;
// Súlyellenőrzés végrehajtása
bool Eredmény = ws.CheckDimensions(Dimensions, out Length, out Width, out Height, outWeight, out Comment);
// Az eredmény vizualizálása
Response.Write("Eredmény: " + Result.ToString() + "");
Response.Write("Hossz: " + Hossz.ToString() + "");
Response.Write("Width: " + Width.ToString() + "");
Response.Write("Magasság: " + Height.ToString() + "");
Response.Write("Súly: " + Weight.ToString() + "");
Response.Write("Súly: "+Megjegyzés+"");

6.2 Szállítási költség kiszámításának módja

Szintaxis:
Hosszú Szállítási költség kiszámítása(string OrderNumber,
lebegő bevallott költség,
Áruk Áruk,
Cím,
Byte TypeOfSeal,
Boolean erős csomagolás,
Boolean CashOnDelivery,
Out DeliveryType típusok,
Out string Megjegyzések)Paraméterek:

Paraméter neve	Bemenet kimenet	típus	Leírás
Rendelésszám	bemenet	húr	Rendelési szám, ha ismert a rendszerben fogyasztó. Ha adott, akkor a számítás a jövőben a rendeléshez lesz kötve.
bejelentett költség	bemenet	úszó	A szállítmány bejelentett értéke. Tovább biztosítás.
Áruk	bemenet	Áruk	Árujegyzék szerkezetek tömbje (Kereskedői kód, Név, Hossz, szélesség, magasság, tömeg, mennyiség)
cím	bemenet	cím	A címzett címe (struktúra: Posta index, Vidék, Terület, Város, Helység, utca, ház, lakás, Kartira)
TypeOfSeal	bemenet	bájtok	választási lehetőség pecsétek, lehetséges értékek:1 Nem szükséges 2 Buborékfólia 3 Töltőanyag
Erős csomagolás	bemenet	Boolean	Szükséges-e egy merev csomag
Utánvétes fizetés	bemenet	Boolean	Utánvét szükséges
típusok	szabadnap	Szállítási típus
Hozzászólások	szabadnap	Szállítási típus	Az elérhető szállítási lehetőségek listája

Leírás:

Módszer által adott paramétereket megjeleníti az elérhető szállítási lehetőségek listáját
(kimeneti paraméter típusok) struktúrák tömbjeként<Идентификатор способа доставки, Наименование способа доставки, Себестоимость доставки, Страховую премию, Затраты на упаковку и маркировку, Адрес нахождения почтового отделения, либо точки самовывоза, Режим работы почтового отделения, либо точки самовывоза, Минимальное количество дней доставки, Максимальное количество дней доставки, Доп.информация>. Ha van kivétel a számítás során, akkor
a hiba leírása jelenik meg a Megjegyzések paraméterben.

Visszatérési érték:

A metódus a számítás egyedi azonosítóját adja vissza, amely szerint a jövőben
módszerrel lehet majd kérni az anyag- és munkaerőköltségek tételes bontását
GetDetailsOfCost.

6.2.1 Példa a CalculateShippingCost metódus meghívására

ws.Credentials = new NetworkCredential("teszt", "teszt");


Cím.Index = "684005";


Address.City = "Jelizovo város";

Cím.Otthon = "16";


aplix.GoodsItem;
Item = new aplix.Goods();
Item.SKU = "216293";

Item.Length = 0,130f;
Item.Width = 0,100f;
Item.Height = 0,001f;
Tétel.Súly = 0,1f;
Tétel.Menny. = 2;
Áru = cikk;
Item = new aplix.Goods();
Item.SKU = "499687";

Item.Length = 0,1331f;
Item.Width = 0,0998f;
Tétel.Magasság = 0,0788f;
Tétel.Súly = 0,575 f;
Tétel.Menny. = 1;
Áru = cikk;
//Adja meg a számológép paramétereit
stringOrderNumber="1234567890";
float DeclaredCost = 36370;
sbyte TypeOfSeal = 1;
bool SturdyPackaging = igaz;
bool CashOnDelivery = false;
aplix.DeliveryType típusok; karakterlánc Megjegyzések;
//számológép hívás
long Status = ws.Calculate ShippingCost(Rendelési szám, Bejelentett költség, Áruk, Cím,Plombolás típusa, Erős csomagolás,Kézpénzes kézbesítés, kiszállítási típusok, kimenő megjegyzések);
//Eredményvizualizáció
Response.Write("Számítási azonosító: "+Status.ToString()+"
");
Response.Write("További információ a számításról: " + Megjegyzések + "
");
Response.Write(@"
");
foreach (aplix.DeliveryType típus a típusokban) (
Response.Write(""+ " "+ " "+ " " + " " + " " + " " + " " + " " " + " " + " " + " " + " " + " "); )
Response.Write("

TypeId	TypeName	TypeDescription	költség	Biztosítás	Postai díjszabás	előkészítési költség	cím	Munkaidő	MinPeriod	MaxPeriod	további információ
" + type.TypeId.ToString() + "	" + type.TypeName + "	" + type.TypeDescription + "	" + type.Cost.ToString() + "	" + type.Insurance.ToString() + "	" + type.PostalRate.ToString() + "	" + type.PreparingCost.ToString() + "	" + típus. Cím + "	" + type.Worktime + "	" + type.MinPeriod.ToString() + "	" + type.MaxPeriod.ToString() + "	" + type.További információ + "

");

 } 


6.3 PushOrder módszer
Szintaxis: 
Hosszú nyomja parancs(
azonosító, 
szám, 
dátum, 
vevő, 
bejelentett költség, 
Fizetendő összeg, 
DeliveryTypeId, 
TypeOfseal, 
Erős csomagolás, 
tevékenység, 
áruk, 
Kézbesítési dátum, 
StartTimeDelivery, 
EndTimeDelivery, 
megjegyzés, 
shipperid, 
jelző) 
Lehetőségek:
Paraméter neve
Bemenet kimenet
típus
Leírás
ID
bemenet
Húr
Rendelési azonosító a rendszerben 
fogyasztó ( egyedi érték)

szám
bemenet
Húr
Rendelési szám az ügyfél rendszerében 
(kinyomtatjuk a megjegyzésekben) 
szállítmányok megjelölésénél)
Dátum
bemenet
dátum idő
A megrendelés dátuma a fogyasztó rendszerében (lesz 
nyomtasd ki kommentben 
szállítmányok jelölése
vevő
bemenet
vevő
Vevői információk, szerkezet 

bejelentett költség
bemenet
úszó
A szállítmány bejelentett értéke.  Tovább 
a feltüntetett összeg kerül kiadásra 
biztosítás.
BeP összege 
támogatás
bemenet
úszó
Összeg 
Nak nek 
fizetés. 
Ha 
rendelés 
előre fizet, majd 0.
DeliveryTypeId
bemenet
int
Kiválasztott módszer azonosítója 
szállítás.
TypeOfSeal
bemenet
int
választási lehetőség 
pecsétek, 
lehetséges 
értékek: 
1 Nem kötelező 
2 Buborékfólia 
3 Kitöltő
Erős csomagolás
bemenet
Boolean
Szükséges-e egy merev 
csomag
Tevékenység
bemenet
Boolean
A megrendelés relevanciája.  Igaz - ha a sorrend 
érvényes, Hamis – a megrendelés törlése esetén.
Áruk
bemenet
Áruk
Terméklista
Kiszállítási dátum
bemenet
dátum idő
Szállítási dátum, kiválasztva kitöltve 
Expressz szállítás
StartTimeDeliv 
ery
bemenet
int
Kívánság lista 
idő 
szállítás 
"VAL VEL", 

szállítás
EndTimeDelivery
bemenet
int
kívánt szállítási idő "Cím", 
futár kiválasztása esetén kitöltve 
szállítás
Megjegyzés
bemenet
Húr
Megjegyzés a rendeléshez
Szállítóazonosító
bemenet
Húr
Azonosító 
feladó, 
töltött 
Ha 
a partnernél 
több webáruház
jelző
bemenet
Húr
Rendelésjelző, kitöltve, ha 
a küldemények fel vannak címkézve 
weboldal
Leírás:
A módszer a megrendeléssel kapcsolatos információkat helyezi el a vállalkozó rendszerében.  rendszer fogyasztó 
továbbítja a megrendelés számát és dátumát, egyedi megrendelés azonosítót, információkat arról 
címét és telefonszámát, bejelentett értékét, a kiszabott összeget 
fizetés, ha van, az árucsatolmány összetétele, a csomagolás típusa és a kiválasztott 
szállítás módja és részletei.
Visszatérési érték:
A metódus egyedi rendelésazonosítót ad vissza a vállalkozó rendszerében.
6.3.1 Példa a PushOrder metódus meghívására

aplix.Delivery ws = new aplix.Delivery(); 
ws.Credentials = new NetworkCredential("teszt", "teszt"); 
// Készítse elő a "Címzett küldése" struktúrát 
aplix.Customer = new aplix.Customer(); 

 // 684005, Kamcsatkai körzet, Elizovsky kerület, Elizovo város, Leninskaya utca, 16. számú ház 
aplix.Cím Cím = new aplix.Address(); 
Cím.Index = "684005"; 
Address.Region = "Kamcsatszkij terület"; 
Address.District = "Elizovsky kerület"; 
Address.City = "Jelizovo város"; 
Address.Street = "Leninskaya street"; 
Cím.Otthon = "16"; 
Customer.Address = Cím; 
Ügyfél.ID = " [e-mail védett]";
Customer.Name = "Szergej"; 
Customer.Email = " [e-mail védett]";
Customer.Phone = "+7(916)975-53-54"; 
//Töltse ki a rendelési paramétereket 
string ID = "2013-1234567890";  // Egyedi rendelésazonosító az ügyfél rendszerében 
string Szám = "1234567890";  // Rendelési szám az ügyfél rendszerében 
DateTime Dátum = new DateTime(2013, 08, 30); 
float DeclaredCost = 36350.0f;  // Deklarált érték 
float AmountToBePaid = 0;  // Nincs utánvét 
int DeliveryTypeId = 4;  // EMC 
sbyte TypeOfSeal = 2;  // Buborékfólia 
bool SturdyPackaging = igaz;  Merev csomagolás (törékeny tárgyakhoz) 
bool Tevékenység = igaz;  // A dokumentum naprakész 
// Tegyük fel, hogy a rendelés 2 tételből áll 
aplix.Goods Goods = new aplix.Goods; 
aplix.GoodsItem; 
Item = new aplix.Goods(); 
Item.SKU = "216293"; 
Item.Name = "SDXC 64Gb Class 10 Transcend"; 
Item.Length = 0,130f; 
Item.Width = 0,100f; 
Item.Height = 0,001f; 
Tétel.Súly = 0,1f; 
Tétel.Menny. = 1; 
Tétel.Ár = 2080,0f; 
Item.VATRate = "VAT18"; 
Áru = cikk; 
Item = new aplix.Goods(); 
Item.SKU = "499687"; 
Item.Name = "Canon EOS 650D Kit Tamron AF 18-270mm fekete"; 
Item.Length = 0,1331f; 
Item.Width = 0,0998f; 
Tétel.Magasság = 0,0788f; 
Tétel.Súly = 0,575 f; 
Tétel.Menny. = 1; 
Tétel.Ár = 34270,0f; 
Item.VATRate = "VAT18"; 
Áru = cikk; 
DateTime DeliveryDate = new DateTime(2013, 09, 05);  //Kézbesítés: 2013. 09. 05 
int StartTimeDelivery = 10;  // szállítási intervallum 10-től 
int EndTimeDelivery = 14;  // 14-ig 
string Comment = "Tesztrendelés"; 
//Húzza be a parancsot a rendszerbe 
long OrderId = ws.PushOrder(ID, Szám, Dátum, Vevő, Bejelentett költség, Fizetendő összeg,Szállítási típusazonosító, Tömítés típusa, Erős csomagolás, Tevékenység, Áruk, Szállítási dátum, Szállítás kezdete,Kézbesítés vége, Megjegyzés, "", ""); 
Response.Write("Rendelésazonosító: " + OrderId.ToString() + "

");


6.4 GetDetailsOfCost módszer
Szintaxis:        DetailsOfCostList GetDetailsOfCost (ID, TypeId) Paraméterek:
Bemenet kimenet 
típus 
Leírás
bemenet 
Hosszú 
A CalculateShippingCost metódus meghívásával kapott számítási azonosító (egyedi érték).
bemenet 
int 

Paraméter neve
ID
TypeId
Leírás: A módszer részletes költséglistát ad vissza a szállítmány címkézéséhez és csomagolásához a megadott számlázási azonosítóhoz és szállítási lehetőség azonosítójához. Visszatérési érték: A metódus struktúrák tömbjét adja vissza 


A tömb minden eleme tartalmazza a költség, mennyiség, ár és költség leírását.
6.4.1 Példa a GetDetailsOfCost metódus meghívására

aplix.Delivery ws = new aplix.Delivery(); 
ws.Credentials = new NetworkCredential("teszt", "teszt"); 
longID = 168;  // A CalculateShippingCost metódussal kapott számítási azonosító 
int TypeId = 3;  // Postai kézbesítés 

aplix.DetailsOfCost Details = ws.GetDetailsOfCost(ID, TypeId); 
//Eredményvizualizáció 
Response.Write("Számítási azonosító: " + ID.ToString() + "

");
Response.Write("Kézbesítési mód azonosítója: " + TypeId.ToString() + "

");
Response.Write(@"

");
foreach(aplix.DetailsOfCost DetailOfCost in Details)
{
Response.Write("" + " " + " " + " " + " " + " ");
}
Response.Write("

Leírás	ár	Menny	költség
" + DetailOfCost.Description + "	" + DetailOfCost.Price.ToString() + "	" + DetailOfCost.Qty.ToString() + "	" + DetailOfCost.Cost.ToString() + "

");


6.5 PushReestr módszer
Szintaxis: Long PushOrder (azonosító, szám, dátum, feladás dátuma, azonosítók) Paraméterek:
Bemenet kimenet 
típus 
Leírás
bemenet 
Húr 
Regisztrációs azonosító a fogyasztói rendszeren (egyedi érték)
bemenet 
Húr 
Annak a szállítási lehetőségnek az azonosítója, amelynek részleteit szeretné megkapni
bemenet 
dátum idő 
Nyilvántartásba vétel dátuma (a szállítmányok átvételi igazolásában szerepel)
bemenet 
dátum idő 
A tételek vállalkozó részére történő átadásának várható időpontja
bemenet 
Húr 
A rendszerleíró adatbázisban szereplő rendelésazonosítók tömbje
Paraméter neve
ID
szám
Dátum
Szállítás időpontja
azonosítók
Leírás: A metódus információkat helyez el a rendszerleíró adatbázisról a végrehajtó rendszerében.  A rendszerfogyasztó a nyilvántartás számát, dátumát, a nyilvántartás egyedi azonosítóját, a tételek átadásának várható időpontját továbbítja a végrehajtónak. Visszatérési érték: A metódus a végrehajtó rendszerében található registry egyedi azonosítóját adja vissza.
6.5.1 Példa a PushReestr metódus meghívására

aplix.Delivery ws = new aplix.Delivery(); 
ws.Credentials = new NetworkCredential("teszt", "teszt"); 
// A rendszerleíró adatbázisban szereplő rendelésazonosítók listája 
string IDs=("2013-1234567890", "2013-1234567891"); 
// A rendszerleíró adatbázis egyedi azonosítója az ügyfélrendszerben 
string ID = "2013-r12345"; 
// Nyilvántartási szám a kliens rendszerben 
string Szám = "r12345"; 
// A nyilvántartás létrehozásának dátuma az ügyfél rendszerében 
DateTime Dátum = new DateTime(2013, 10, 22); 
// A megrendelések szállításra történő átadásának becsült dátuma 
DateTime DateOfShipment = new DateTime(2013, 10, 23); 
// Számítási részletek lekérése 
long ReestID = ws.PushReestr(ID, szám, dátum, kiszállítás dátuma, azonosítók); 
//Eredményvizualizáció 
Response.Write("Registry ID: " + ReestID.ToString() + "

");


6.6 GetTrackNumbers módszer
Szintaxis: dátum és idő GetTrackNumbers(DateOfLastGetting, TrackNumbers) Paraméterek:
Bemenet kimenet 
típus 
Leírás
bemenet 
dátum idő 
A számok utolsó sikeres fogadásának dátuma.  A paraméter az átvitt adatok mennyiségének csökkentésére szolgál, és nem a korábban feltöltött adatok megkettőzésére szolgál.
bemenet 
pályaszám 
Műsorszámok tömbje megrendelésekhez
Paraméter neve
DateOfLastGetting
TrackNumbers
Leírás: A metódus azoknak a számoknak a listáját adja vissza, amelyek a DateOfLastGetting és a következő időszak rendeléseihez voltak társítva. aktuális idő.  Az eredmény a TrackNumbers kimeneti paraméterbe kerül.  Az Activity tulajdonság igazra van állítva, ha a műsorszám száma naprakész, ellenkező esetben false.  Vannak olyan helyzetek, amikor egy küldeményhez egy pályaszámot rendelnek, majd néhány második pályaszám után, ebben az esetben az eredetileg hozzárendelt pályaszám irrelevánssá válik. Visszatérési érték: A metódus azt a dátumot és időpontot adja vissza, amelyre a feltöltött adatok relevánsak. Adott érték a GetTrackNumbers metódus következő meghívásakor kell használni a DateOfLastGetting paraméterben.
6.6.1 Példa a GetTrackNumbers metódus meghívására

aplix.Delivery ws = new aplix.Delivery(); 
ws.Credentials = new NetworkCredential("teszt", "teszt"); 
// A műsorszámok utolsó sikeres fogadásának dátuma 
DateTime DateOfLastGetting = new DateTime(2013, 08, 01); 
aplix.TrackNumber TrackNumber; 
// A számok listájának beszerzése 
DateTime NewDateOfLastGetting = ws.GetTrackNumbers(DateOfLastGetting, out TrackNumbers); 
//Eredményvizualizáció 
Response.Write("NewDateOfLastGetting: " + NewDateOfLastGetting.ToString() +"

");
Response.Write(@"

");
foreach(aplix.TrackNumber TrackNumber a TrackNumberben)
{
Response.Write("" + " " + " " + " " + " ");
}
Response.Write("

Rendelés azonosító	pályaszám	Tevékenység
" + TrackNumber.OrderID.ToString() + "	" + TrackNumber.Number + "	"+TrackNumber.Activity+"

");


Az API (Application Programming Interface) az bizonyos reprezentáció adatok az alkalmazások közötti interakcióhoz.  Egy adott esetben a szerver válaszalkalmazásként működhet.  Az API egy leírt formátum, amelynek az adatcsere mindkét oldalának meg kell felelnie.
A különféle API-k technológiája interakciós módszerek halmaza.  Az API rendszer ilyen vagy olyan formában mindenhol megtalálható.  Például okostelefont tartunk a kezünkben jegyvásárlási alkalmazással.  A "legmagasabb" szinten az alkalmazás grafikus részét látjuk adatbeviteli mezőkkel.  Egy adott napra kérünk járatokat az útvonalon, és mi történik abban a pillanatban:
A mobilalkalmazás kérést generál a szerver felé.  A kérés meghatározott formátumban készül.  Például: Indulás:MoszkvaDME,Érkezés:AmszterdamAMS,Dátum:01-01-2017,Ühelyek:2,Osztály:Gazdaságos.  Ez a sor szigorú formátumot tartalmaz - Címsor:Érték, minden érték vesszővel elválasztva, kötelező mezők Indulás, Érkezés és Dátum, ha nincs más adat megadva, akkor ezek alapértelmezés szerint a következők lesznek: Ülőhelyek:1, Osztály:Gazdaság.
A légitársaság szervere megkapja ezt a kérést, és a program megérti, hogy meg kell találnia a járatok és árakat.
A szerver SQL-ben éri el az adatbázist, amely egyben az API privát reprezentációja is
Az adatbázis a fájlrendszer API-n keresztül éri el a fájlt
A fájlrendszer az API protokollon keresztül éri el a merevlemezt.
Folytathatja az elmélyítést, de nyilvánvaló, hogy minden programozási feladat API-hierarchiát épít.
Manapság ilyen vagy olyan formában minden számítógépes formában lévő információt az API képvisel.
API rendszereket fejlesztünk a felső réteg számára, ahol a következő fogyasztó a kliens alkalmazás.
API típusok osztályozása
A megoldandó feladattól függően az API átviteli protokollok lehetnek szabványosak és saját formátumúak is.  A leggyakrabban használt szabványosított protokollok, amelyek lehetővé teszik a fejlesztők számára, hogy kész modulokat használjanak a feldolgozáshoz, ami csökkenti az alkalmazás fejlesztésének idejét.  Különféle specifikus típusokat használnak bizonyos előnyök eléréséhez, mint például csökkentett forgalom, parancsfelismerés sebessége, és bizonyos esetekben - ez az egyetlen lehetőség - saját formátum fejlesztése - például videó sugárzása efemerisz komponenssel.
A továbbított információ típusa szerint az API a következő formátumokra oszlik:
Szabványos API protokollok 
Szöveg

Bináris 
Sorban
személyzet

Az ügyfél-szerver interakció típusától függően a következő típusok a leggyakoribbak:
Batch 
HTTP/HTTPS
Aljzatok

eljárási (protokoll)
Sorban
Adás
API rendszerek alkalmazása
Minden online szolgáltatásnak és rendszernek nyilvános API-ja van.  Bizonyos esetekben az API-hozzáférés használatához fizetnie kell egy előfizetésért vagy bizonyos számú találatért.  Ha egy olyan online szolgáltatás létrehozása a célja, amely bizonyos információkat nyújt, fordítson különös figyelmet az API-ra.  Az API-funkciók megközelítése és megfelelő dokumentálása a siker kulcsa.  Minden harmadik féltől származó fejlesztő, aki később létrehoz további alkalmazások szükségesek ennek a protokollnak a használatához.
Elterjedt gyakorlat, hogy az API szerver az egyetlen adatreprezentációja a teljes szolgáltatásnak, és a kliens rész csak az alkalmazáson keresztül működik.  Élénk példák a Viberre, Instagramra, Swarmra – ezeket az alkalmazásokat csak mobilnak is nevezik (csak mobilban).  Ennek érdekében létre kell hozni egy olyan rendszert, amely elosztja a terhelést az API-kiszolgálók között, amely lehetővé teszi egy 24 órás, skálázható kapacitású szolgáltatás létrehozását.  A szerver rész elkészítése előtt azonnal fel kell mérni ennek az eseménynek a lehetőségeit, és ezeket a lehetőségeket figyelembe kell venni a programok fejlesztésénél.
A stabilitás elérése érdekében fejlesztések a Linux környezethez és annak rendszerszolgáltatások.  Ez annak köszönhető, hogy ez operációs rendszer rugalmasabb, erőforrás-igényesebb és rendelkezik magas szint naplózás és hibakeresés összeomlások esetén.  A webszervereket kiadóként ill speciális szolgáltatások.  Számos fejlesztést végeztünk a többszálú szolgáltatásban az API-rendszerek biztosítására.
Leírtuk, hogyan működik, nézzük meg, hogyan lehet pénzt keresni vele?  Az első módszer önmagát javasolja - szolgáltatásnyújtás az API-n keresztül.  Közvetlenül értékesíthet szolgáltatásokat vagy árukat – ha kapcsolatba lép az étterem API-jával, az étel házhozszállítására rendelhető.  Vagy biztosítani hasznos szolgáltatás fizetett alapon, például számviteli beszámolók készítése.
Az API-n keresztüli bevételszerzés második módja több rendszer egy szolgáltatásba történő összevonása.  A légitársaságok API típusát már tárgyaltuk, de több tucat vagy akár több száz légitársaság létezik.  Mostanra népszerűvé váltak a jegyértékesítő szolgáltatások - az Aviasales, a OneTwoTrip, a Momondo, amelyek valójában nem képviselnek semmit, csak különböző API-kat vesznek át a légitársaságoktól, és közzéteszik saját szolgáltatásukat, amely adatokat gyűjt ezektől a cégektől.  Ez a gyakorlat nagyon elterjedt és nagyon jövedelmező.
Az API-val való pénzszerzés harmadik módja az „adatkeverés”.  Ha ismét visszatérünk a légitársasághoz, akkor ezek alapján hozhatunk létre kapcsolódó szolgáltatást, például biztosítást.  Olyan szolgáltatást vagy alternatív API belépési pontot teszünk közzé, ahol a járatok mellett egy adott repüléshez kapcsolódó biztosítási információk is felkerülnek az API adatok közé.  Így tegyék például a légitársaságok vagy a közvetítők, kibővítve az API-t, hogy tájékoztassák a szállodákat.
API technológiák létrehozása
Szolgáltatásainkat API-szerverek létrehozására kínáljuk a korábban leírt valamennyi típusú és protokollal.  Tapasztalattal rendelkezünk különböző nagy terhelésű rendszerek interakciójának kiépítésében.  A kimeneten nem csak egy kész szervert (fekete doboz) mutatunk be, hanem azt is Teljes leírás jegyzőkönyv tervdokumentáció formájában.  Ezt a protokollleírást a következő fejlesztők használhatják ezen adatok felhasználásával, akár nyílt hozzáférésű nyílt forráskódhoz.
Magán a szerveren kívül létrehozhatunk egy nyomkövető és elemző rendszert is, amely jelzi a hibákat és meghaladja a szerver(ek) szabályozott terhelését.