REST ja RESTful API arendamise põhitõed

Veebiarendajad räägivad sageli REST põhimõtted ja RESTful andmete arhitektuur, see on kaasaegse arengu oluline aspekt, kuid mõnikord võib see olla uskumatult segane. REST ei ole iseenesest tehnoloogia, vaid pigem teatud organisatsiooniliste põhimõtetega API loomise meetod. Need põhimõtted on suunata arendajaid ja luua üldisem keskkond API-taotluste töötlemiseks.

Selles postituses tahaksin selgitada RESTful arendustavasid lindude silmist. Ma tahan tegeleda the mida mitte kuidas. Kuigi ma puudutan mõlemat piirkonda, on see postitus tehtud kõigile, kes on veebiarenduses, kuid lihtsalt ei saa aru REST API-de kontseptsioonist.

REST veebiarendajatele

Akronüüm REST tähistab Esinduslik riigiülekanne. See võib tunduda mõnevõrra segane ja wiki sisestamine muudab selle veelgi segadusttekitavamaks. Kuid terminoloogiat on võimalik lihtsustada.

REST on vaid seeria andmete edastamiseks kasutatavad suunised ja arhitektuurilised stiilid. Seda rakendatakse tavaliselt veebirakendustes, kuid see võib edastada ka tarkvara.

Akronüüm API tähistab rakenduse programmeerimise liidest, mis on ühendamine teiste raamatukogude või rakendustega. Windowsil on mitu API-d ja Twitteril on ka veebipõhine API, kuigi nad täidavad erinevaid ülesandeid erinevate eesmärkidega.

Kõik kombineerides on RESTful API-d REST-arhitektuuri järgivad API-d.

Mis on täpselt REST-arhitektuur?

See on koht, kus on raske täpsustada. Siiski on mõned arhitektuurilised konstandid, näiteks:

Järjepidevus kogu API-s
Kodakondsuseta olemasolu, s.o serveripoolsed istungid puuduvad
Kasutamine HTTP olekukoodid vajaduse korral
Kasutamine URL-i lõpp-punktid loogilise hierarhiaga
Versioon URL-is mitte HTTP-päistes

Puuduvad liiga spetsiifilised juhised nagu W3C HTML5 spetsifikatsioon, mis võib põhjustada segadust ja RESTi terminoloogia ebakindluse miasma.

Ülaltoodud loend neid ei tohiks pidada rasketeks ja kiireteks reegliteks, kuigi need kehtivad kõige kaasaegsematele RESTful API-dele.

REST on a kerge metoodika mis muudab selle HTTP-andmete jaoks ideaalseks. Sellepärast sai REST veebis nii populaarseks ja miks seda laialdaselt peetakse parimaks valikuks API arendamiseks.

Nagu Vinay Sahni seda paneb, “API on arendaja kasutajaliides.” Kõik peaks olema lihtne kasutada ja pakkuma suurt kasutaja kogemust. RESTful API-d püüavad just seda teha.

RESTful API-de jaoks vajalikud võtmed

Need nõuanded on API-de kontekstis rangelt veebirakenduste jaoks. See tähendab seda HTTP on nõue, ja see tähendab sageli seda API-andmed paiknevad välises serveris. Uurime, kuidas RESTful API-d API kasutaja poolel töötavad.

API kasutaja on veebiarendaja, kes suudab ehitada skripti, mis ühendub välise API-serveriga, seejärel edastatakse vajalikud andmed HTTP kaudu. Arendaja saab seejärel kuvada andmeid oma veebilehel ilma välise serveri isikliku juurdepääsuta (nagu Twitteri andmete tõmbamine).

Üldiselt on olemas neli käsku harjunud juurdepääs RESTful API-dele:

GET objekti allalaadimiseks
POST uue objekti loomiseks
PUT objekti muutmiseks või asendamiseks
DELETE objekti eemaldamiseks

Kõik need meetodid peaksid olema API-kõnega serverile öelda, mida teha.

Enamik veebi API-sid lubada ainult GET päringuid andmete väljalülitamiseks välisest serverist. Autentimine on vabatahtlik, kuid kindlasti on hea mõte, kui lubate potentsiaalselt kahjulikke käske PUT või DELETE.

Kuid paljud RESTful API-d ei lähe isegi kaugele. Mõtle Pokéapi, mis on tasuta Pokémon API andmebaas. See on avalikkusele avatud korraliku määra piiramisega (kasutajate piiramine teatud aja jooksul API taotlustega), kuid võimaldab ainult GET ressurssidele juurdepääsu meetod. See võib olla kõnekeelne nimetus a ainult tarbimise API.

Tagasi tüübid on samuti olulised ja peaksid säilitama homogeensuse kõigi ressursside puhul. JSON on populaarne tagasipöördumisviis, millel on veebipõhised andmed, mis selgitavad õigeid andmestruktuure.

RESTful API-d kasutavad API objektide nimisõnad, ja tegude tegemiseks kasutatavad tegusõnad nende objektide kohta. Autentimine võib olla osa sellest, samuti võib selle osa olla kiirusepiirang. Kuid väga lihtne API saab, kui kasutajate piiranguid palju ei pööra.

API ressursside kasutamine

Tavaliselt on avalikud API-d kättesaadav otse veebisaidi aadressidest. See tähendab URL-i struktuur on oluline, ja seda tuleks kasutada ainult API taotluste puhul.

Mõned URL-id võivad sisaldada prefiksi kataloogi / v2 / eelmise API uuendatud versiooni 2 jaoks. See on tavaline arendajatele, kes ei soovi oma 1.x API-d odavneda, kuid soovivad siiski pakkuda uusimat struktuuri.

Ma tõesti nautisin seda postitust põhilised URL-i struktuurid ja teiste teenuste näited.

Pange tähele, et lõpp-punkt on tagastamisandmed muutuvad põhinevad dramaatiliselt HTTP meetod. Näiteks, GET otsib sisu POST loob uue sisu. Taotlus võib viidata samale lõpp-punktile, kuid tulemus võib olla väga erinev.

Näiteid võrgus nägemine võib aidata teil mõisteid paremini mõista. Me nägime juba Pokeapi, kuid siin on veel midagi reaalse maailma API näited tutvuma:

Reddit API
GitHub API
Flickri API
Pinterest API

Oma API loomine

Oma API loomise protsessi ei tohiks kergelt võtta, kuid see ei ole ka nii keeruline, kui arvate. See võtab aega arusaamine API disainilahendustest ja parimatest tavadest ehitada midagi reaalset väärtust.

Iga API peab olema ühenda oma serveriga teatud liiki andmete tagastamiseks. Sa ei pea mitte ainult seda koodi kirjutama, vaid ka tagastamisandmete vormindamist. Muud võimalikud nõuded hõlmavad autentimine ja kiiruse piiramine, nii et API rajamine ei ole kindlasti südame nõrk.

Aga vaatame mõned põhilised tõekspidamised API arhitektuur.

Ehita lõpp-punktid

API arengu üks aspekt on hoone lõpp-punktid. Millal ressursside loomine soovite kasutada nimesõnu, mitte verge. See tähendab, et API andmed peaksid tagastama isiku, koha või asja, kõige sagedamini konkreetse atribuudiga asi (näiteks piiksuma ja kõik selle metaandmed).

Nimisõnade nimetamine võib olla raske, kuid see on API arengu oluline aspekt. Lihtsustamine on parim, kui see on võimalik.

Suur arutelu on ainsus ja mitmuses nimisõnad. Kui tegite Twitteri API-d, võib teil esmalt olla objektide grupp (st piiksuma), seejärel objekti objekt (teine) (st piiksuma ID).

 $ / tweet / 15032934882934 $ / tweets / 15032934882934

Sel juhul väidan, et ainsus vorm tundub parem. See kehtib eriti siis, kui tagastatakse ainult üks ressurss. Kuid ei ole dokumenteeritud 100% õiget vastust, nii et tehke seda, mis sobib teie projekti jaoks kõige paremini.

Määra tagastamise tüüp

Teine kaalutlus on tagastamise tüübi andmed. Enamik veebikasutajaid ootab JSONi sisu, nii et see on tõenäoliselt parim valik. XML on teine valik, kui soovite mõlemat pakkuda. Kuid JSON on veebiarendajate hulgas API põhiline tagastamise tüüp.

API arendamisel läheb palju rohkem, seega soovitan kõigepealt mängida API-dega. Nii näete, kuidas teised arendajad oma API-sid ehitavad, ja loodetavasti saate tuttavaks tüüpiliste nõuetega.

Kui te alles alustate, siis palun kaaluge neid õpetusi:

REST API juhendaja sait
Lihtsa REST API kirjutamine
RESTful veebiteenuse loomine

Täiendavad ressursid

Parim viis veebirakenduste arendamiseks on praktikas. Antud teooria on alati väärt õppimist, sest see võimaldab teil suhelda arendajatega ja mõista, kuidas asjad toimivad.

Aga hea koht alustamiseks API arendusega on ühendamine teistesse API-desse esiteks. Lugege kliendipoolsete ühenduste põhialuseid ja sealt saate liikuda serveripoolse API arenduse juurde, luues omaenda API-lt nullist.

Kui see on sinu eesmärk, siis palun arvestage järgmisi vahendeid, et aidata oma reisi ajal.

Raamatud

REST API disainilahenduse juhend
RESTful Web API-d
RESTful Web Services kokaraamat
Häirimatu REST: juhend täiusliku API väljatöötamiseks

Artiklid

Algaja juhend HTTP ja RESTi jaoks
RESTful API loomine
RESTful Resource Naming Guide
REST API loomine MEAN Stacki abil