REST in ja RESTfulin API-kehityksen perusasiat

Web-kehittäjät puhuvat usein REST-periaatteet ja RESTful-tietorakenne, koska se on tärkeä osa modernia kehitystä, mutta joskus se voi olla uskomattoman sekava. REST ei ole itsessään teknologia vaan pikemminkin menetelmä, jolla luodaan API: ta tietyillä organisaatioperiaatteilla. Nämä periaatteet ohjaavat kehittäjiä ja luovat yleisemmän ympäristön API-pyyntöjen käsittelyyn.

Tässä viestissä haluan selittää RESTful-kehityskäytäntöjä lintuperspektiivistä. Haluan käsitellä mitä pikemminkin kuin millä tavalla. Vaikka aion koskettaa molempia alueita, tämä viesti tehdään kaikille, jotka ovat Web-sivuston kehitykseen, mutta eivät yksinkertaisesti pysty ymmärtämään REST-sovellusliittymien käsitettä.

REST Web-kehittäjille

Lyhenne REST tarkoittaa Edustava valtion siirto. Tämä saattaa kuulostaa hieman hämmentävältä, ja wiki-merkintä tekee siitä hämmentävän. Terminologiaa voidaan kuitenkin yksinkertaistaa.

REST on vain yksi sarja tiedonsiirtoon käytettävät ohjeet ja arkkitehtuurityylit. Sitä sovelletaan yleisesti web-sovelluksiin, mutta se voi myös siirtää tietoja ohjelmistoihin.

Acronym API tarkoittaa Application Programming Interface -ohjelmaa, joka on yhteydet muihin kirjastoihin tai sovelluksiin. Windowsissa on useita sovellusliittymiä, ja Twitterissä on myös web-sovellusliittymä, vaikka ne suorittavat erilaisia tehtäviä eri tavoitteilla.

Yhdistämällä kaikki yhdessä, RESTful-sovellusliittymät ovat sovellusliittymiä, jotka noudattavat REST-arkkitehtuuria.

Mikä on REST-arkkitehtuuri?

Täällä on vaikea määritellä erityispiirteitä. On kuitenkin olemassa joitakin arkkitehtonisia vakioita, kuten:

johdonmukaisuus koko API: ssa
Luonnottomuus, eli ei palvelinpuolen istuntoja
Käyttö HTTP-tilakoodit tarvittaessa
Käyttö URL-päätepisteet looginen hierarkia
Versio URL-osoitteessa pikemminkin kuin HTTP-otsikoissa

Ei ole mitään erityisiä ohjeita, kuten W3C HTML5 -spesifikaatiota, joka voisi johtaa sekaannukseen ja epävarmuuden miasmaan REST-terminologian ympärillä.

Myös yllä oleva luettelo ei pidä pitää kovina ja nopeana sääntöinä, vaikka ne koskevat nykyaikaisia RESTful-sovellusliittymiä.

REST on a kevyt menetelmä mikä tekee siitä täydellisen HTTP-tietoihin. Siksi REST tuli niin suosittua verkossa, ja miksi sitä pidetään yleisesti parhaana vaihtoehtona API-kehitykselle.

Kuten Vinay Sahni esittää, “API on kehittäjän käyttöliittymä.” Kaikkien tulisi olla helppokäyttöisiä, ja niillä on hyvä käyttäjäkokemus. RESTful API: t pyrkivät tekemään juuri niin.

Tärkeimmät takaisinkytkennät RESTful API: ille

Nämä vinkit ovat sovellusliittymien yhteydessä tiukasti web-sovelluksia varten. Se tarkoittaa, että HTTP on vaatimus, ja se tarkoittaa usein sitä API-tiedot ovat ulkoisessa palvelimessa. Tarkastellaan, miten RESTful API: t toimivat API-käyttäjän puolella.

API-käyttäjä on web-kehittäjä, joka voi rakentaa komentosarjan, joka muodostaa yhteyden ulkoiseen API-palvelimeen, jolloin tarvittavat tiedot välitetään HTTP: n kautta. Kehittäjä voi sitten näyttää tiedot verkkosivuillaan ilman henkilökohtaista pääsyä ulkoiseen palvelimeen (kuten Twitter-tietojen vetäminen).

Yleisesti ottaen on olemassa neljä komentoa tottunut käyttää RESTful-sovellusliittymiä:

SAADA objektin hakemiseksi
LÄHETTÄÄ uuden objektin luomiseen
LAITTAA objektin muokkaamiseen tai vaihtamiseen
POISTAA objektin poistamiseksi

Jokaisen näistä menetelmistä tulisi olla API-puhelun kanssa kertoa palvelimelle, mitä tehdä.

Suurin osa verkkosovelluksista vain sallia SAADA pyynnöt vetää tietoja ulos ulkoisesta palvelimesta. Todennus on valinnainen, mutta varmasti hyvä idea, kun sallit mahdollisesti haitalliset komennot LAITTAA tai POISTAA.

Kuitenkin monet RESTful API: t eivät edes mene niin pitkälle. Harkitse Pokéapi, joka on ilmainen Pokémon API -tietokanta. Se on avoinna yleisölle kunnollisen korkorajoituksen avulla (rajoitetaan käyttäjiä tiettyyn määrään API-pyyntöjä tietyn ajan kuluessa), mutta se sallii vain SAADA menetelmä resurssien käyttämiseen. Tämä voi olla puhekielellä nimeltään a vain kulutus-API.

Palautustyypit ovat myös tärkeitä, ja niiden pitäisi säilyttää homogeenisuus kaikkien resurssien osalta. JSON on suosittu palautustyyppi, jossa on online-tiedot, jotka selittävät asianmukaiset tietorakenteet.

RESTful API: t käyttävät API-objektien substantiivit, ja verbit toimien suorittamiseksi näihin kohteisiin. Autentikointi voi olla osa tätä, nopeuden rajoittaminen voi myös olla osa tätä. Mutta hyvin yksinkertainen sovellusliittymä voi saada ilman, että käyttäjän rajoitukset ovat huolestuttavia.

API-resurssien käyttö

Yleiset API: t ovat tyypillisesti saatavilla suoraan verkkosivustojen osoitteista. Tämä tarkoittaa URL-rakenne on tärkeä, ja sitä tulisi käyttää vain API-pyyntöihin.

Jotkin URL-osoitteet voivat sisältää etuliitteen hakemiston / V2 / päivitetyn aiemman API-version 2. Tämä on yleistä kehittäjille, jotka eivät halua alentaa 1.x API: ta, mutta haluavat silti tarjota uusimman rakenteen.

Olen todella nauttinut tästä postista URL-osoitteiden perusrakenteet ja esimerkkejä muista palveluista.

Huomaa, että päätepiste on palautustiedot muuttuvat perustuu dramaattisesti HTTP-menetelmä. Esimerkiksi, SAADA etsii sisältöä LÄHETTÄÄ luo uutta sisältöä. Pyyntö voisi viitata samaan loppupisteeseen, mutta tulos voi olla hyvin erilainen.

Esimerkkien tarkasteleminen verkossa voi auttaa ymmärtämään käsitteitä selkeämmin. Olemme jo nähneet Pokeapin, mutta tässä on muutakin reaalimaailman API-esimerkkejä tarkastella:

Reddit API
GitHub API
Flickrin sovellusliittymä
Pinterest API

Oman API: n rakentaminen

Oman API: n rakentamisprosessia ei pidä ottaa kevyesti, mutta se ei myöskään ole niin monimutkainen kuin luulisi. Se kestää ymmärrystä API-muotoilusta ja parhaista käytännöistä rakentaa jotain todellista arvoa.

Jokaisen API: n on oltava muodosta yhteys palvelimeen palauttaa jonkinlaiset tiedot. Sinun ei tarvitse vain kirjoittaa koodia, vaan tarvitset myös palautustietojen alustamisen. Muita mahdollisia vaatimuksia ovat mm todennus ja nopeuden rajoittaminen, joten API: n rakentaminen ei varmasti ole sydämen heikko.

Mutta katsotaanpa joitakin perusperiaatteita API-arkkitehtuuria.

Rakenna päätepisteet

API: n kehittämisen yksi näkökohta on rakennuksen päätepisteet. Kun resurssien luominen haluat käyttää substantiiveja, ei verbejä. Tämä tarkoittaa, että API-tietojen pitäisi palauttaa henkilö, paikka tai asia, useimmiten se on asia, jolla on erityisiä ominaisuuksia (esimerkiksi tweet ja kaikki sen metatiedot).

Nimien käyttäminen voi olla vaikeaa oppia, mutta tämä on API-kehityksen olennainen osa. Yksinkertaistaminen on paras mahdollisuuksien mukaan.

Suuri keskustelu on yksittäinen vs. monikko substantiiveja. Jos teit Twitter-sovellusliittymän, sinulla voi olla ensin objektiryhmä (ts. Tweet), sitten objektikohdan toinen (ts. Tweet-tunnus).

 $ / tweet / 15032934882934 $ / tweets / 15032934882934

Tässä tapauksessa väittäisin, että yksittäinen muoto näyttää paremmalta. Tämä pätee erityisesti silloin, kun vain yksi resurssi palautetaan. Mutta ei ole dokumentoitua 100% oikeaa vastausta, joten tee mitä tahansa sopii parhaiten projektisi.

Aseta palautustyyppi

Toinen näkökohta on palautustyypin tiedot. Useimmat web-käyttäjät odottavat JSON-sisältöä, joten se on todennäköisesti paras vaihtoehto. XML on toinen vaihtoehto, jos haluat tarjota molempia. JSON on kuitenkin olennainen API-palautustyyppi web-kehittäjien keskuudessa.

API-kehitykseen menee paljon enemmän, joten suosittelen ensin API-sovellusten käyttöä. Näin voit nähdä, miten muut kehittäjät rakentavat API: t, ja toivottavasti voit tuntea tyypilliset vaatimukset.

Jos olet juuri aloittamassa, kannattaa harkita näitä dev-ohjeita.

REST API -opetusohjelma
Yksinkertaisen REST-API: n kirjoittaminen
RESTful Web -palvelun rakentaminen

Muita resursseja

Paras tapa oppia web-sovellusten kehitystä on käytännössä. Annetun teorian kannattaa aina tutkia, koska sen avulla voit keskustella kehittäjien kanssa ja ymmärtää, miten asiat toimivat.

Mutta hyvä paikka aloittaa API-kehityksellä liitetään muihin sovellusliittymiin ensimmäinen. Opi asiakaspuolen yhteyksien perusteet, ja sieltä voit siirtyä palvelinpuolen API-kehitykseen luomalla oman sovellusliittymän tyhjästä.

Jos tämä on tavoite, ota huomioon seuraavat resurssit, jotka auttavat matkan aikana.

Kirjat

REST API Design Rulebook
RESTful Web API: t
RESTful Web Services -kokikirja
Undisturbed REST: Opas Perfect-sovelluksen suunnitteluun

Artikkelit

Aloittelijan opas HTTP: lle ja RESTille
Luodaan RESTful API
RESTful Resource Naming Guide
REST-API: n luominen MEAN-pinolla