REST ir RESTful API plėtros pagrindai

Žiniatinklio kūrėjai dažnai kalba apie tai REST principai ir atnaujinama duomenų architektūra, kadangi tai yra esminis šiuolaikinio vystymosi aspektas, tačiau kartais tai gali būti neįtikėtinai paini. REST yra ne pati technologija, o veikiau API sukūrimo su tam tikrais organizaciniais principais metodas. Šiais principais vadovaujama kūrėjams ir sukuriama visuotinė aplinka API užklausų apdorojimui.

Šiame pranešime norėčiau paaiškinti „RESTful“ vystymosi praktiką paukščių akių vaizdu. Noriu spręsti ką vietoj kaip. Nors paliesiu abi sritis, šis įrašas yra skirtas visiems, kurie įeina į interneto svetainių kūrimą, bet tiesiog negali suvokti REST API koncepcijos.

REST for Web Developers

Akronimas REST reiškia Atstovavimas valstybiniam perdavimui. Tai gali atrodyti šiek tiek paini, o wiki įrašas verčia jaustis dar painiau. Tačiau galima supaprastinti terminiją.

REST yra tik serija gairių ir architektūros stilių, naudojamų duomenų perdavimui. Paprastai jis taikomas žiniatinklio programoms, bet taip pat gali perduoti duomenis programinei įrangai.

Akronimas API reiškia „Application Programming Interface“, kurios yra „Metodiniai“ metodai prisijungti prie kitų bibliotekų ar programų. „Windows“ turi kelis API, o „Twitter“ taip pat turi žiniatinklio API, nors atlieka skirtingas užduotis su skirtingais tikslais.

Kartu sujungus RESTful API yra API, kurios atitinka REST architektūrą.

Kas yra REST architektūra?

Čia sunku nustatyti specifiką. Tačiau yra keletas architektūrinių konstantų, tokių kaip:

• Nuoseklumas visoje API
• Be pilietybės egzistavimas, t. y. nėra serverio pusės sesijų
• Naudojimas HTTP būsenos kodai prireikus
• Naudojimas URL pabaigos taškai su logine hierarchija
• Versija URL vietoj HTTP antraštių

Nėra jokios pernelyg specifinės gairės, pvz., W3C HTML5 specifikacijos, kurios gali sukelti painiavą, ir netikrumo apie REST terminiją miasma.

Taip pat minėtas sąrašas neturėtų būti laikomos sudėtingomis taisyklėmis, net jei jie tinka daugeliui modernių „RESTful“ API.

REST yra a lengva metodika todėl jis puikiai tinka HTTP duomenims. Štai kodėl REST tapo toks populiarus internete, ir kodėl jis plačiai vertinamas kaip geriausias pasirinkimas API kūrimui.

Kaip teigia Vinay Sahni, “API yra kūrėjo vartotojo sąsaja.” Viskas turėtų būti paprasta naudoti ir suteikti puikią naudotojo patirtį. „RESTful API“ siekia tai padaryti.

Pagrindiniai atkuriamieji RESTful API

Šie patarimai yra API kontekste griežtai žiniatinklio programoms. Tai reiškia, kad HTTP yra reikalavimas, ir dažnai tai reiškia API duomenys yra talpinami išoriniame serveryje. Apsvarstykite, kaip RESTful API veikia API naudotojo pusėje.

API vartotojas yra žiniatinklio kūrėjas, kuris gali sukurti scenarijų, jungiančio į išorinį API serverį, tada reikiami duomenys perduodami per HTTP. Tada kūrėjas gali rodyti duomenis savo svetainėje neturint asmeninės prieigos prie išorinio serverio (kaip ištraukti „Twitter“ duomenis).

Apskritai yra keturios komandos įpratęs pasiekti RESTful API:

1. GET objektui gauti
2. POST sukurti naują objektą
3. PUT objektui modifikuoti ar pakeisti
4. IŠTRINTI objektui pašalinti

Kiekvienas iš šių metodų turėtų būti su API skambutis pasakyti serveriui, ką daryti.

Dauguma žiniatinklio API leidžiama tik GET prašymus ištraukti duomenis iš išorinio serverio. Autentifikavimas yra neprivalomas, bet tikrai yra gera idėja, kai leidžiama kaip galimai žalingos komandos PUT arba IŠTRINTI.

Tačiau daugelis RESTful API netgi nueina toli. Apsvarstykite Pokéapi, kuris yra nemokama Pokémon API duomenų bazė. Tai atvira visuomenei su tinkamo tarifo ribojimu (naudotojų apribojimas tam tikru API užklausų skaičiumi per tam tikrą laikotarpį), tačiau leidžia tik GET prieigos prie išteklių. Tai gali būti šnekamoji kalba vadinama a vartojimo tik API.

Grąžinimo tipai taip pat svarbu ir turėtų išlaikyti homogeniškumą visų išteklių. JSON yra populiarus sugrįžimo tipas su internetinėmis specifikacijomis, kurios paaiškina tinkamas duomenų struktūras.

Naudojamos pasikartojančios API API objektų daiktavardžiai, ir veiksmažodžių veiksmai apie tuos objektus. Autentifikavimas gali būti šio elemento dalis, taip pat gali būti apribojimo norma. Bet labai paprasta API gali gauti be didelių susirūpinimo naudotojų apribojimais.

Prieiga prie API išteklių

Paprastai yra viešos API prieinama iš tiesioginių interneto svetainių adresų. Tai reiškia URL struktūra yra svarbi, ir turėtų būti naudojami tik API užklausoms.

Kai kuriuose URL gali būti prefiksų katalogas / v2 / atnaujintos ankstesnės API versijos 2. Tai yra paplitusi programuotojams, nenorintiems nuvertinti savo 1.x API, bet vis tiek nori pasiūlyti naujausią struktūrą.

Man tikrai patiko šis pranešimas pagrindinės URL struktūros ir kitų paslaugų pavyzdžiai.

Atkreipkite dėmesį, kad pasekmė yra grąžinimo duomenys pasikeis dramatiškai pagrįstas HTTP metodas. Pavyzdžiui, GET atkuria turinį, o POST sukuria naują turinį. Prašymas gali būti toks pats, tačiau rezultatas gali būti labai skirtingas.

Pavyzdžių peržiūra internete gali padėti suprasti sąvokas aiškiau. Mes jau pamatėme Pokeapi, bet čia yra ir kita realaus pasaulio API pavyzdžiai perskaityti:

• Reddit API
• „GitHub“ API
• „Flickr“ API
• Pinterest API

Savo API kūrimas

Savo API kūrimo procesas neturėtų būti priimtas lengvai, bet taip pat nėra taip sudėtingas, kaip manote. Tai užtrunka supratimą apie API dizaino modelius ir geriausią praktiką sukurti kažką realios vertės.

Kiekviena API turi būti prisijungti prie serverio grąžinti tam tikrus duomenis. Tam reikia ne tik rašyti kodą, bet ir formatuoti grąžinimo duomenis. Kiti galimi reikalavimai apima autentifikavimas ir greičio ribojimas, todėl API kūrimas tikrai nėra už silpną širdį.

Bet pažvelkime kai kurie pagrindiniai principai API architektūros.

Sukurkite galutinius taškus

Vienas API plėtros aspektas pastato parametrai. Kada kuriant išteklius norite naudoti daiktavardžius, o ne veiksmažodžius. Tai reiškia, kad API duomenys turėtų būti grąžinti asmeniui, vietai ar dalykui, dažniausiai tai yra dalykas su konkrečiais atributais (pavyzdžiui, Čivināšana ir visi jo metaduomenys).

Gali būti sunku mokytis įvardinti daiktavardžius, tačiau tai yra esminis API plėtros aspektas. Supaprastinimas yra geriausias, kai tik įmanoma.

Didelė diskusija vienaskaita ir daugiskaita daiktavardžiai. Jei padarėte „Twitter“ API, pirmiausia galite turėti objekto grupę (t. Y. „Tweet“), tada antrą objektų elementą (t. Y. „Tweet ID“).

 $ / tweet / 15032934882934 $ / tweets / 15032934882934 

Šiuo atveju manau, kad vienaskaitos forma atrodo geriau. Taip yra ypač tada, kai grąžinamas tik vienas šaltinis. Tačiau nėra jokio dokumentais patvirtinto 100% teisingo atsakymo, todėl atlikite viską, kas geriausiai tinka jūsų projektui.

Nustatykite grąžinimo tipą

Kitas aspektas yra grąžinimo tipo duomenys. Dauguma žiniatinklio naudotojų tikisi JSON turinio, todėl tai yra geriausias variantas. XML yra dar vienas pasirinkimas, jei norite pasiūlyti abu. Tačiau JSON yra pagrindinis API grįžimo tipas tarp žiniatinklio kūrėjų.

Yra daug daugiau, kaip API kūrimas, todėl pirmiausia rekomenduoju žaisti su API. Tokiu būdu galite pamatyti, kaip kiti kūrėjai kuria savo API, ir tikimės, kad susipažinsite su tipiniais reikalavimais.

Jei tik pradėsite, prašome apsvarstyti šių „dev“ vadovų persmelkimą:

• REST API vadovo svetainė
• Paprasta REST API rašymas
• „RESTful Web Service“ kūrimas

Kiti ištekliai

Geriausias būdas išmokti žiniatinklio programų kūrimą yra praktika. Suteikta teorija visada verta studijuoti, nes tai leidžia jums bendrauti su kūrėjais ir suprasti, kaip viskas veikia.

Bet gera vieta pradėti API kūrimą yra prisijungti prie kitų API Pirmas. Sužinokite apie kliento pusės ryšių pagrindus ir iš ten galite pereiti prie serverio pusės API kūrimo sukurdami savo API nuo nulio.

Jei tai yra jūsų tikslas, prašome apsvarstyti šiuos išteklius, kad galėtumėte padėti savo kelionei.

Knygos

• REST API dizaino taisyklės
• „RESTful“ žiniatinklio API
• Atnaujinta „Web Services Cookbook“
• Netinkamas REST: „Perfect API“ kūrimo vadovas

Straipsniai

• Pradedančiųjų vadovas HTTP ir REST
• RESTful API kūrimas
• „RESTful Resource Naming Guide“
• REST API kūrimas naudojant „MEAN Stack“