A REST és a RESTful API fejlesztésének alapjai

A webfejlesztők gyakran beszélnek A REST elvek és a RESTful adat architektúra, mivel ez a modern fejlődés döntő aspektusa, de néha hihetetlenül zavaró lehet. A REST önmagában nem technológia, hanem inkább egy technológia az API-k létrehozásának módja bizonyos szervezeti elvekkel. Ezek az elvek a fejlesztők irányítását, valamint az API kérések feldolgozásához szükséges univerzálisabb környezet kialakítását szolgálják.

Ebben a bejegyzésben szeretném megmagyarázni a RESTful fejlesztési gyakorlatokat madárszemüvegből. Szeretnék kezelni a mit ahelyett, hogy a hogyan. Bár mindkét területet megérintem, ez a bejegyzés bárki számára készült, aki webes fejlesztésbe kerül, de egyszerűen nem tudja megragadni a REST API-k fogalmát.

REST webes fejlesztők számára

A REST rövidítés jelentése Reprezentatív állami kimutatás. Ez kissé zavarónak tűnhet, és a wiki-bejegyzés még zavarosabbá teszi. De lehetséges a terminológia egyszerűsítése.

A REST csak egy sor az adatátvitelhez használt irányelvek és építészeti stílusok. Általában a webalkalmazásokra alkalmazzák, de adatokat is továbbíthat a szoftverekbe is.

Az API rövidítés az Application Programming Interface (Alkalmazásprogramozási interfész), amely a következő módszerek kapcsolatba más könyvtárakkal vagy alkalmazásokkal. A Windows több API-val rendelkezik, és a Twitter web API-t is tartalmaz, bár különböző feladatokat lát el különböző célokkal.

Mindezeket kombinálva a RESTful API-k olyan API-k, amelyek követik a REST architektúrát.

Pontosan mi a REST architektúra?

Itt nehéz megfogalmazni a sajátosságokat. Vannak azonban olyan építészeti konstansok, mint például:

Következetesség az egész API-n
Hontalan lét, vagyis nincsenek szerveroldali munkamenetek
Használata HTTP állapotkódok adott esetben
Használata URL-végpontok logikai hierarchiával
Verzió az URL-ben a HTTP fejlécek helyett

Nincsenek olyan túlzottan specifikus irányelvek, mint a W3C HTML5 specifikáció, ami zavart okozhat, és a REST terminológiával kapcsolatos bizonytalanság miasma.

Továbbá, a fenti lista nem tekinthető kemény és gyors szabályoknak, még akkor is, ha a legtöbb modern RESTful API-ra igaz.

A REST a könnyű módszer ami HTTP adatokhoz tökéletes. Ez az oka annak, hogy a REST annyira népszerűvé vált az interneten, és miért tartják széles körben az API fejlesztés legjobb választásaként.

Ahogy Vinay Sahni hozza, “egy API fejlesztői felhasználói felület.” Mindennek könnyen használhatónak és nagyszerű felhasználói élménynek kell lennie. A RESTful API-k erre törekednek.

Kulcsfeltételek az RESTful API-k számára

Ezek a tippek az API-k kontextusában vannak szigorúan a webes alkalmazásokhoz. Ez azt jelenti A HTTP követelmény, és ez gyakran azt jelenti az API adatok egy külső kiszolgálón tárolódnak. Vizsgáljuk meg, hogy a RESTful API-k hogyan működnek az API felhasználó oldalán.

Az API felhasználó az a webfejlesztő, aki külső API-kiszolgálóhoz csatlakozó szkriptet tud létrehozni, majd a szükséges adatokat HTTP-n keresztül továbbítja. A fejlesztő ezután megjelenítheti az adatokat a saját honlapján anélkül, hogy személyes hozzáféréssel rendelkeznénk a külső szerverhez (mint például a Twitter adatainak húzása).

Általánosságban elmondható, hogy vannak négy parancs szokott hozzáférjen a RESTful API-khoz:

KAP egy objektum letöltéséhez
POST új objektum létrehozásához
PUT egy objektum módosításához vagy cseréjéhez
TÖRÖL egy objektum eltávolításához

Mindegyik módszernek meg kell lennie az API-hívással megmondani a szervernek, mit kell tennie.

A webes API-k túlnyomó többsége csak engedélyezze KAP kérelmek az adatok külsõ kiszolgálóról történõ húzásához. A hitelesítés opcionális, de minden bizonnyal jó ötlet, ha engedélyezi a potenciálisan káros parancsokat PUT vagy TÖRÖL.

Azonban sok RESTful API még nem megy ilyen messzire. Fontolja meg a Pokéapi-t, amely egy ingyenes Pokémon API adatbázis. A nyilvánosság számára tisztességes mértékű korlátozás (nyitva van egy bizonyos időtartamig korlátozott számú API kérésre), de csak lehetővé teszi a felhasználók számára KAP módszer az erőforrások eléréséhez. Ezt beszédesen lehet a csak fogyasztási API.

Visszatérési típusok fontosak, és meg kell megtartják a homogenitást minden erőforrás esetében. A JSON egy népszerű visszatérési típus az online specifikációkkal, amelyek a megfelelő adatstruktúrákat magyarázzák.

RESTful API-k használata főnevek az API objektumokhoz, és műveletek végrehajtására szolgáló igék ezeken a tárgyakon. Ennek része lehet a hitelesítés, ennek részét képezheti a sebességkorlátozás is. De egy nagyon egyszerű API-t a felhasználói korlátok nagy aggodalma nélkül érheti el.

API erőforrások elérése

A nyilvános API-k jellemzően hozzáférhető a közvetlen webhelycímekből. Ez azt jelenti, hogy az URL-struktúra fontos, és csak API kérések esetén használható.

Egyes URL-ek tartalmazhatnak egy prefix könyvtárat is / V2 / egy korábbi API frissített 2. verziójához. Ez gyakori azoknak a fejlesztőknek, akik nem akarják leértékelni az 1.x API-t, de még mindig szeretnék a legújabb struktúrát kínálni.

Nagyon élveztem ezt a hozzászólást alapvető URL-struktúrák és példák más szolgáltatásokból.

Ne feledje, hogy a végpont a visszatérési adatok megváltoznak drámaian alapul HTTP módszer. Például, KAP közben megkeresi a tartalmat POST új tartalmat hoz létre. A kérés ugyanarra a végpontra mutathat, de az eredmény nagyon eltérő lehet.

Az online példák áttekintése segíthet megérteni a fogalmak egyértelműbbé tételét. Már láttuk a Pokeapit, de itt van más valós világ API példái megismer

Reddit API
GitHub API
Flickr API
Pinterest API

Saját API létrehozása

A saját API építésének folyamatát nem szabad enyhén venni, de nem is olyan bonyolult, mint gondolnád. Ez egy az API-tervezési minták és a legjobb gyakorlatok megértése építeni valódi értéket.

Minden API-nak meg kell felelnie csatlakozzon a kiszolgálóhoz valamilyen adat visszajuttatása. Ehhez nem csak kódot kell írni, hanem a visszatérési adatok formázásához is szükséges. Egyéb lehetséges követelmények közé tartozik hitelesítés és sebességkorlátozás, így az API építése természetesen nem a szíve gyenge.

De nézzük meg néhány alapvető alapelv API-architektúra.

Építési végpontok

Az API fejlesztésének egyik aspektusa épület végpontjai. Amikor erőforrások létrehozása főnevek, nem igék. Ez azt jelenti, hogy az API-adatoknak személynek, helynek vagy dolognak kell visszatérniük, leggyakrabban egy bizonyos tulajdonságokkal rendelkező dolog (például egy tweet és az összes metaadat).

A főnevek megnevezése nehéz tanulni, de ez az API fejlesztésének döntő aspektusa. Az egyszerűsítés a lehető legjobb.

Nagy vita van szinguláris és többes számú főnév. Ha Twitter-API-t készítettél, előfordulhat, hogy először az objektumcsoport (azaz tweet), majd az objektumelem második (azaz tweet ID).

 $ / tweet / 15032934882934 $ / tweets / 15032934882934

Ebben az esetben azt állítom, hogy az egyedülálló forma jobban néz ki. Ez különösen igaz, ha csak egy erőforrást küld vissza. De nincsenek dokumentált 100% -os helyes válaszok, így tegyünk meg mindent, ami a legjobban megfelel a projektednek.

Állítsa be a visszatérési módot

Egy másik megfontolás visszatérési típusú adatok. A legtöbb webes felhasználó JSON-tartalmat vár, így valószínűleg ez a legjobb megoldás. Az XML egy másik lehetőség, ha mindkettőt kívánja ajánlani. A JSON azonban az alapvető API visszatérési típus a webfejlesztők között.

Sokkal több az API fejlesztés, ezért ajánlom először az API-kkal játszani. Így láthatja, hogy más fejlesztők építsék API-kat, és remélhetőleg megismerkedjen a tipikus követelményekkel.

Ha csak elkezdesz dolgozni, kérjük, fontolja meg ezeket a segédprogramokat:

REST API oktatóhely
Egyszerű REST API írása
RESTful webszolgáltatás kiépítése

További források

A webes alkalmazások fejlesztésének legjobb módja a gyakorlat. A megengedett elmélet mindig érdemes megvizsgálni, mert lehetővé teszi, hogy beszéljen a fejlesztőkkel és megértse, hogyan működnek a dolgok.

De jó hely az API-fejlesztéshez más API-khoz való csatlakozás első. Ismerje meg az ügyféloldali kapcsolatok alapjait, és onnan a kiszolgálóoldali API-fejlesztés felé mozdulhat el saját API létrehozásával..

Ha ez az Ön célja, kérjük, vegye figyelembe az alábbi erőforrásokat az utazás során.

Könyvek

REST API tervezési kézikönyv
RESTful web API-k
RESTful Web Services főkönyv
Zavartalan REST: Útmutató a tökéletes API tervezéséhez

Cikkek

Kezdő útmutató a HTTP-hez és a REST-hez
RESTful API létrehozása
RESTful Resource Naming Guide
A REST API létrehozása a MEAN Stack használatával