Osnove REST in RESTful API razvoj

Spletni razvijalci pogosto govorijo o tem Načela REST in arhitektura RESTful podatkov, ker je ključni vidik sodobnega razvoja, včasih pa je lahko neverjetno zmedena. REST ni tehnologija sama po sebi, ampak bolj metoda ustvarjanja API-jev z nekaterimi organizacijskimi načeli. Ta načela vodijo razvijalce in ustvarjajo bolj univerzalno okolje za obdelavo zahtev API.

V tej objavi bi rad razložil razvojne prakse RESTful iz ptičje perspektive. Želim se spopasti kaj namesto kako. Čeprav se bom dotaknil obeh področij, je ta objava namenjena vsem, ki se ukvarjajo s spletnim razvojem, vendar preprosto ne morejo razumeti koncepta REST API-jev.

REST za spletne razvijalce

Kratica REST pomeni Predstavniški prenos države. To lahko zveni nekoliko zmedeno, zato je vhodni vnos še bolj zmeden. Vendar je mogoče poenostaviti terminologijo.

REST je samo serija smernice in arhitekturne sloge, ki se uporabljajo za prenos podatkov. Običajno se uporablja za spletne aplikacije, lahko pa posreduje podatke tudi programski opremi.

Kratica API je kratica za Application Programming Interface, ki je metoda povezovanje z drugimi knjižnicami ali aplikacijami. Windows ima več API-jev, Twitter pa ima tudi spletni API, čeprav opravljajo različne naloge z različnimi cilji.

Vse skupaj združujejo, API-ji RESTful so API-ji, ki sledijo arhitekturi REST.

Kaj točno je REST arhitektura?

Tukaj je težko določiti posebnosti. Vendar pa obstajajo nekatere arhitekturne konstante, kot so:

• Doslednost v celotnem API-ju
• Obstoj brez državljanstva, ni sej na strani strežnika
• Uporaba Stanje kode HTTP po potrebi
• Uporaba Končne točke URL z logično hierarhijo
• Različice v URL-ju namesto v glavah HTTP

Ni preveč specifičnih smernic, kot je specifikacija W3C HTML5, ki bi lahko povzročila zmedo, in miazma negotovosti glede terminologije REST.

Tudi zgoraj navedeni seznam ne bi smeli obravnavati kot težka pravila, čeprav veljajo za najsodobnejše API-je RESTful.

REST je a lahka metodologija zaradi česar je popoln za podatke HTTP. Zato je REST postal tako priljubljen na spletu in zakaj je na splošno ocenjen kot najboljša izbira za razvoj API-jev.

Kot pravi Vinay Sahni, “API je uporabniški vmesnik razvijalca.” Vse bi moralo biti preprosto za uporabo in zagotoviti odlično uporabniško izkušnjo. RESTful API-ji so namenjeni prav temu.

Ključni vnosi za API-je RESTful

Ti nasveti so v kontekstu API-jev strogo za spletne aplikacije. To pomeni da Zahteva se HTTP, in to pogosto pomeni podatki API-ja gostujejo na zunanjem strežniku. Oglejmo si, kako RESTful API-ji delujejo na strani uporabnika API-ja.

Uporabnik API je spletni razvijalec, ki lahko zgradi skript, ki se poveže z zunanjim strežnikom API, nato pa se potrebni podatki prenesejo prek HTTP. Razvijalec lahko nato prikaže podatke na svoji spletni strani brez osebnega dostopa do zunanjega strežnika (kot vlečenje podatkov iz storitve Twitter).

Na splošno obstajajo štiri ukaze navajen dostop do API-jev RESTful:

1. GET za pridobitev predmeta
2. POST za ustvarjanje novega objekta
3. PUT za spreminjanje ali zamenjavo predmeta
4. DELETE za odstranitev predmeta

Vsaka od teh metod bi morala biti opravljeno s klicem API povedati strežniku, kaj naj počne.

Velika večina spletnih API-jev dovolite samo GET zahtevkov izvleči podatke iz zunanjega strežnika. Preverjanje pristnosti je neobvezno, toda zagotovo je dobra ideja, če dovolite, da bi utegnili poškodovati ukaze PUT ali DELETE.

Vendar pa ni veliko RESTful API-jev celo iti tako daleč. Razmislite o Pokéapi, ki je brezplačna baza podatkov Pokémon API. Odprta je za javnost z dostojnim omejevanjem stopnje (omejevanje uporabnikov na določeno število zahtev API-jev v določenem časovnem obdobju), vendar le omogoča GET metodo za dostop do virov. To se lahko kolokvijalno imenuje a samo za porabo.

Vrste vračanja prav tako pomembne in bi morale ohrani homogenost za vsa sredstva. JSON je priljubljen tip vrnitve s spletnimi specifikacijami, ki pojasnjujejo ustrezne podatkovne strukture.

RESTful API-ji uporabljajo samostalniki za objekte API, in glagoli za izvajanje dejanj na te predmete. Avtentifikacija je lahko del tega, del tega pa je lahko tudi omejitev hitrosti. Toda zelo preprost API lahko doseže, ne da bi veliko skrb za omejitve uporabnikov.

Dostop do virov API

Javni API-ji so običajno dostopni z neposrednih spletnih naslovov. To pomeni struktura URL je pomembna, in naj se uporablja samo za zahteve API.

Nekateri URL-ji lahko vključujejo imenik s predpono, kot je / v2 / za posodobljeno različico prejšnjega API-ja. To je običajno za razvijalce, ki ne želijo amortizirati API 1.x, vendar še vedno želijo ponuditi najnovejšo strukturo.

Res sem uživala v tem postu osnovne strukture URL in primeri iz drugih storitev.

Upoštevajte, da je končna točka podatki o vračilu se bodo spremenili dramatično temelji na Metoda HTTP. Na primer, GET pridobi vsebino, medtem ko POST ustvarja novo vsebino. Zahteva lahko kaže na isto končno točko, vendar je lahko rezultat zelo različen.

Pregledovanje primerov na spletu vam lahko pomaga razumeti jasnejše koncepte. Pokeapi smo že videli, toda tukaj je še nekaj drugih primeri v realnem svetu API pregledati:

• Reddit API
• GitHub API
• Flickr API
• Pinterest API

Zgradite svoj API

Proces izgradnje lastnega API-ja ne bi smel biti sprejemljiv, ampak tudi ni tako zapleten, kot si morda mislite. Potrebno je razumevanje vzorcev oblikovanja API in najboljših praks zgraditi nekaj prave vrednosti.

Vsak API mora povežite se s strežnikom vrniti podatke neke vrste. Ne samo, da morate za to narediti kodo, temveč morate tudi formatirati povratne podatke. Druge potencialne zahteve vključujejo preverjanje pristnosti in omejevanje hitrosti, tako da izgradnja API-ja zagotovo ni za omedlevice.

Toda poglejmo nekaj osnovnih načel arhitekture API.

Zgradite končne točke

Eden od vidikov razvoja API je končne točke stavbe. Kdaj ustvarjanje virov želite uporabljati samostalnike, ne glagoli. To pomeni, da morajo podatki API-ja vrniti osebo, kraj ali stvar, najpogosteje pa je stvar s posebnimi lastnostmi (npr. cvrkutati in vsi njegovi metapodatki).

Lahko je težko naučiti imena samostalnikov, vendar je to ključni vidik razvoja API. Poenostavitev je najboljša, kadar je to mogoče.

Velika razprava je ednina vs množina samostalniki. Če ste ustvarjali API za Twitter, boste morda najprej imeli skupino predmetov (tj. Tweet), nato element predmeta drugega (tj. Tweet ID).

 $ / tweet / 15032934882934 $ / tvitov / 15032934882934 

V tem primeru bi trdil, da ednina izgleda bolje. To velja še posebej, če se vrne samo en vir. Vendar ni nobenega dokumentiranega 100% pravilnega odgovora, zato naredite vse, kar je najbolje za vaš projekt.

Nastavite vrsto vrnitve

Še en premislek je vrniti vrsto podatkov. Večina spletnih uporabnikov pričakuje vsebino JSON, zato je to verjetno najboljša možnost. XML je druga izbira, če želite ponuditi oboje. Vendar je JSON osnovni tip vrnitve API med spletnimi razvijalci.

V razvoj API-ja je veliko več, zato priporočam, da se najprej igrate z API-ji. Na ta način lahko vidite, kako drugi razvijalci gradijo svoje API-je, in upamo, da se boste seznanili s tipičnimi zahtevami.

Če ste šele začeli, razmislite o tem, da jih odstranite:

• Spletna učilnica REST API
• Pisanje enostavnega API-ja REST
• Izdelava spletne storitve RESTful

Nadaljnji viri

Najboljši način za učenje razvoja spletnih aplikacij je s prakso. Odobrena teorija je vedno vredna študija, saj vam omogoča, da se pogovarjate z razvijalci in razumete, kako stvari delujejo.

Ampak dobro mesto za začetek z razvojem API je povezovanje v druge API-je prvi. Izvedite osnove povezav na strani odjemalca in od tam lahko premaknete razvoj API-jev na strani strežnika tako, da ustvarite svoj API od začetka.

Če je to vaš cilj, razmislite o naslednjih virih za pomoč na poti.

Knjige

• REST API Design Pravilnik
• Spletni API-ji RESTful
• RESTful Cookie za spletne storitve
• Nedotaknjen REST: Vodnik za oblikovanje popolnega API-ja

Členi

• Vodnik za začetnike za HTTP in REST
• Ustvarjanje API-ja RESTful
• RESTful Vodnik poimenovanja virov
• Ustvarjanje API-ja REST z uporabo MEAN Stack