REST un RESTful API attīstības pamati

Web izstrādātāji bieži runā REST principi un atjaunota datu arhitektūra, tā kā tas ir būtisks mūsdienu attīstības aspekts, bet dažreiz tas var būt neticami mulsinoši. REST nav pati tehnoloģija, bet drīzāk metode API izveidei ar noteiktiem organizatoriskiem principiem. Šie principi ir orientēti uz izstrādātājiem un radīt vispārīgāku vidi API pieprasījumu apstrādei.

Šajā amatā es gribētu izskaidrot RESTful attīstības praksi no putna lidojuma. Es vēlos risināt the kas nevis kā. Lai gan es pieskartos abām jomām, šis ieraksts ir sagatavots ikvienam, kurš ir iesaistīts tīmekļa izstrādē, bet vienkārši nespēj saprast REST API koncepciju.

REST Web izstrādātājiem

Akronīms REST nozīmē Pārstāvība valsts pārziņā. Tas var likties nedaudz mulsinoši, un wiki ieraksts padara to skaļāku. Bet ir iespējams vienkāršot terminoloģiju.

REST ir tikai virkne vadlīnijas un arhitektūras stili, ko izmanto datu pārraidei. To parasti izmanto tīmekļa lietojumprogrammās, bet var arī nodot datus programmatūrai.

Akronīms API apzīmē lietojumprogrammu saskarni, kas ir savienojumu ar citām bibliotēkām vai lietojumprogrammām. Windows ir vairākas API, un Twitter ir arī tīmekļa API, lai gan tās veic dažādus uzdevumus ar dažādiem mērķiem.

Apvienojot to kopā, RESTful API ir API, kas seko REST arhitektūrai.

Kas tieši ir REST arhitektūra?

Šeit ir grūti noteikt specifiku. Tomēr ir dažas arhitektūras konstantes, piemēram:

• Konsekvence visā API
• Bezvalstnieks, t.i. nav servera puses sesiju
• Izmantošana HTTP statusa kodi vajadzības gadījumā
• Izmantošana URL beigu punkti ar loģisku hierarhiju
• Versija URL nevis HTTP galvenes

Nav nevienas pārāk specifiskas vadlīnijas, piemēram, W3C HTML5 specifikācija, kas varētu izraisīt neskaidrības, un neskaidrības miasma ap REST terminoloģiju.

Arī iepriekš minētais saraksts nevajadzētu uzskatīt par stingriem un ātriem noteikumiem, pat ja tie attiecas uz modernākajām RESTful API.

REST ir a viegla metodoloģija kas padara to par perfektu HTTP datiem. Tieši tāpēc REST kļuva tik populārs tīmeklī, un kāpēc tā tiek uzskatīta par vislabāko izvēli API izstrādei.

Kā to norāda Vinay Sahni, “API ir izstrādātāja lietotāja interfeiss.” Viss ir viegli lietojams un nodrošina lielisku lietotāja pieredzi. RESTful API mērķis ir to darīt.

Galvenie atkāpšanās ceļi atjaunojošām API

Šie padomi ir API kontekstā tikai tīmekļa lietojumprogrammām. Tas nozīmē ka HTTP ir prasība, un tas bieži nozīmē to API dati tiek glabāti ārējā serverī. Apskatīsim, kā RESTful API darbojas API lietotāja pusē.

API lietotājs ir tīmekļa izstrādātājs, kurš var veidot skriptu, kas savienojas ar ārēju API serveri, un tad nepieciešamie dati tiek nodoti HTTP. Pēc tam izstrādātājs var parādīt datus savā tīmekļa vietnē bez personas piekļuves ārējam serverim (piemēram, čivināt datus).

Vispārīgi runājot, ir četras komandas agrāk piekļūt RESTful API:

1. GŪT objekta ielādei
2. POST lai izveidotu jaunu objektu
3. PUT objekta pārveidošanai vai nomaiņai
4. DELETE objekta noņemšanai

Katrai no šīm metodēm jābūt ar API zvanu lai pastāstītu serverim, ko darīt.

Lielākā daļa tīmekļa API atļaut tikai GŪT pieprasījumus izvilkt datus no ārēja servera. Autentifikācija ir neobligāta, bet, protams, tā ir laba ideja, pieļaujot potenciāli kaitīgas komandas PUT vai DELETE.

Tomēr daudzas RESTful API nav tik tālu. Apsveriet Pokéapi, kas ir bezmaksas Pokémon API datu bāze. Tas ir atvērts sabiedrībai ar pienācīgas likmes ierobežojumu (ierobežojot lietotāju uz noteiktu skaitu API pieprasījumu laika periodā), bet tikai ļauj GŪT metode piekļuvei resursiem. To var sarunvalodā saukt par a tikai patēriņa API.

Atgriešanās veidi ir svarīgi, un tiem vajadzētu saglabā viendabīgumu visiem resursiem. JSON ir populārs atgriešanās veids ar tiešsaistes specifikācijām, kas izskaidro pareizas datu struktūras.

Izmanto atjaunojošās API lietvārdi API objektiem, un darbības vārdi uz šiem objektiem. Autentifikācija var būt daļa no šī, likmes ierobežošana var būt arī daļa no šī. Bet ļoti vienkārša API var iegūt, neraizējoties par lietotāju ierobežojumiem.

Piekļuve API resursiem

Publiskās API parasti ir pieejamas tiešās tīmekļa vietnes adresēs. Tas nozīmē URL struktūra ir svarīga, un to vajadzētu izmantot tikai API pieprasījumiem.

Dažos URL var būt arī prefiksu katalogs / v2 / lai atjauninātu iepriekšējās API 2. versiju. Tas ir izplatīts tiem izstrādātājiem, kuri nevēlas amortizēt savu 1.x API, bet joprojām vēlas piedāvāt jaunāko struktūru.

Man patiešām patika šis amats pamata URL struktūras un citu pakalpojumu piemēri.

Ņemiet vērā, ka beigu punkts ir atgriezīsies dati dramatiski balstās uz HTTP metode. Piemēram, GŪT atrod saturu POST rada jaunu saturu. Pieprasījums varētu norādīt uz to pašu parametru, bet rezultāts varētu būt ļoti atšķirīgs.

Pārskatot piemērus tiešsaistē, varēsiet saprast koncepcijas skaidrāku. Mēs jau redzējām Pokeapi, bet šeit ir daži citi reālā pasaules API piemēri saprast:

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

Savas API izveide

Savas API izveides process nedrīkst būt viegls, bet tas arī nav tik sarežģīts, kā jūs varētu domāt. Tas aizņem izpratne par API dizaina modeļiem un labāko praksi veidot kaut ko reālu vērtību.

Katrai API jābūt savienojumu ar savu serveri atgriezt datus. Lai to izdarītu, jums ir ne tikai jāraksta kods, bet arī jāformatē atgriešanās dati. Citas iespējamās prasības ietver autentifikāciju un likmes ierobežošana, tāpēc API izveide noteikti nav par sirdi vāju.

Bet paskatīsimies daži pamatprincipi API arhitektūra.

Veidot beigu punktus

Viens no API izstrādes aspektiem ir ēkas parametri. Kad resursu radīšana jūs vēlaties izmantot lietvārdus, nevis vārdus. Tas nozīmē, ka API datiem vajadzētu atgriezties personai, vietai vai lietai, visbiežāk tas ir lieta ar īpašiem atribūtiem (piemēram, čivināt un visus tā metadatus).

Var būt grūti mācīties nosaukt lietvārdus, bet tas ir būtisks API attīstības aspekts. Vienkāršošana ir vislabākā iespēja, kad vien iespējams.

Liela diskusija ir vienskaitlis pret daudzskaitli lietvārdi. Ja veidojat čivināt API, iespējams, vispirms būs objekta grupa (t. I., Čivināt), pēc tam otrā objekta vienība (t. I., Čivināt ID).

 $ / tweet / 15032934882934 $ / tweets / 15032934882934 

Šajā gadījumā es teiktu, ka vienskaitlis ir labāks. Tas jo īpaši ir tad, ja tiek atgriezts tikai viens resurss. Bet nav dokumentētas 100% pareizas atbildes, tāpēc dariet visu, kas vislabāk atbilst jūsu projektam.

Iestatiet atgriešanās veidu

Vēl viens apsvērums ir atgriešanās tipa dati. Lielākā daļa tīmekļa lietotāju sagaida JSON saturu, tāpēc tas ir labākais risinājums. XML ir vēl viena izvēle, ja vēlaties piedāvāt abus. Tomēr JSON ir galvenais API atgriešanas veids starp tīmekļa izstrādātājiem.

API izstrādē ir daudz vairāk, tāpēc es vispirms iesaku spēlēt ar API. Tādā veidā jūs varat redzēt, kā citi izstrādātāji veido savas API, un, cerams, jūs iepazīsieties ar tipiskajām prasībām.

Ja jūs tikai sākat darbu, lūdzu, apsveriet šo devu apmācības:

• REST API apmācības vietne
• Vienkārša REST API rakstīšana
• RESTful tīmekļa pakalpojuma izveide

Papildu resursi

Labākais veids, kā mācīties tīmekļa lietotņu izstrādi, ir prakse. Piešķirtā teorija vienmēr ir vērts mācīties, jo tā ļauj sarunāties ar izstrādātājiem un saprast, kā lietas darbojas.

Bet laba vieta, kur sākt ar API attīstību, ir savienojumu ar citām API vispirms. Uzziniet klienta puses savienojumu pamatus, un no turienes varat pāriet uz servera puses API izstrādi, izveidojot savu API no nulles.

Ja tas ir jūsu mērķis, lūdzu, apsveriet šādus resursus, lai palīdzētu ceļojumā.

Grāmatas

• REST API dizaina rokasgrāmata
• Atjaunojošas tīmekļa API
• RESTful Web Services pavārgrāmatu
• Netraucēts REST: ceļvedis Perfect API izstrādei

Raksti

• Iesācēja ceļvedis HTTP un REST
• RESTful API izveide
• RESTful Resource Naming Guide
• REST API izveide, izmantojot MEAN Stack