Kumotaan "vain POST" API-myytti, selitetään miksi se johtuu API-suunnitteluperiaatteiden väärinkäsityksestä ja selvennetään RESTful- ja RPC-arkkitehtuurityylien asianmukaiset käyttökohteet.
Äskettäin kiinnitin huomiota keskusteluun siitä, pitäisikö API:t suunnitella käyttämällä vain "POST". Tutkittuani tätä väittelyä huomasin, että ei vain ole merkityksetöntä, mistä ihmiset kiistelevät, vaan se myös paljastaa monien kehittäjien väärinymmärryksen API-suunnittelun olemuksesta. Tänään syvennymme API-suunnittelun ydinajatuksiin ja näemme, miksi tätä väittelyä ei pitäisi olla olemassa ensinkään.
Kehittäjät, jotka puolustavat "vain POST" -käyttöä korvatakseen RESTful API -määrittelyt, eivät selvästikään ole ymmärtäneet API-suunnittelun tärkeintä kohtaa. Heidän väitteensä sisältävät tavallisesti:
Pintapuolisesti nämä argumentit vaikuttavat järkeviltä. Mutta todellisuudessa tämä näkökanta sekoittaa HTTP-menetelmien valinnan API-suunnittelutyyleihin, jotka ovat kaksi eri tasoista ongelmaa. POST on vain yksi HTTP-protokollan menetelmä, kun taas REST on API-suunnittelutyyli.
Ennen kuin keskustelemme tietyistä API-tyyleistä, meidän on ymmärrettävä, mikä API-suunnittelun ytimenä on. Hyvä API:n tulisi olla:
RESTful API on vain yksi monista API-suunnittelutyyleistä, joka keskittyy resursseihin ja resurssien toimintoihin. Otetaanpa yksinkertainen blogijärjestelmä esimerkiksi nähdäksesi, miten RESTful API suunnitellaan:
Hanki kaikki artikkelit:
Hanki tietty artikkeli:
Luo uusi artikkeli:
Päivitä artikkeli:
Poista artikkeli:
Tässä esimerkissä näemme:
Tämä suunnittelutapa tekee API:sta intuitiivisemman ja itseään selittävämmän, mikä helpottaa kehittäjiä ymmärtämään jokaisen päätepisteen toiminnan.
RPC (Remote Procedure Call) -tyylisen API-suunnittelun tavoitteena on tehdä etäpalvelukutsuista näyttämään yhtä yksinkertaisilta kuin paikallisten funktioiden kutsuminen.
Mielenkiintoista on, että ne, jotka puolustavat "vain POST" -käyttöä, eivät ehkä ymmärrä, että he itse asiassa kuvaavat RPC-tyyliä.
Verrattuna RESTful API:ihin, RPC keskittyy enemmän itse operaatioon kuin resurssiin. Tästä syystä RPC-tyyliset API:t käyttävät yleensä "verbi + substantiivi" -muotoa, kuten getProduct(productId) tai createUser(userData).
Monissa RPC-toteutuksissa kaikki operaatiot lähetetään tavallisesti POST-pyyntöinä samaan päätepisteeseen, jossa tietty toimenpide ja parametrit määritellään pyyntökehossa. Tämä on syy, miksi ajatus "vain POST" on itse asiassa lähempänä RPC: tä kuin REST.
Esimerkiksi RPC-tyylinen "hanki tuote" -pyyntö, joka perustuu HTTP:hen, saattaa näyttää tältä:
Modernit RPC-kehykset, kuten gRPC, tarjoavat tehokkaampia ja tehokkaampia toteutuksia. Käytetään tätä esimerkkiä osoittamaan RPC-tyyliä:
Ensin määritämme palvelun ja viestin muodon (käyttäen Protocol Buffers):
Sitten tämän palvelun käyttäminen Node.js-asiakkaassa on yhtä helppoa kuin paikallisen funktion kutsuminen:
Tässä RPC-tyylisessä esimerkissä näemme:
GetArticle ja CreateArticle).await odottamaan tulosta, mikä edelleen piilottaa verkkoviestinnän monimutkaisuuden.Vaikka alakerros voi silti käyttää HTTP/2:ta kuljetusprotokollana, RPC-kehykset (kuten gRPC) tarjoavat kehittäjille abstraktiotason, joka saa etäkutsut näyttämään ja tuntumaan paikallisten toimintokutsuilta.
Siksi voimme nähdä, että suurin osa "vain POST" ja RESTful API -väittelyistä pitäisi olennaisesti olla keskusteluja näistä kahdesta API-tyylistä: REST ja RPC. Kuitenkin avain on tunnistaa, että molemmilla tyyleillä on omat soveltamisalueensa ja valinnan tulisi perustua projektin erityistarpeisiin, ei henkilökohtaisiin mieltymyksiin.
Nyt kun ymmärrämme erot REST:n ja RPC:n välillä, katsotaanpa niiden soveltuvia skenaarioita:
Tyylivalinnan tulisi perustua omiin erityistarpeisiisi. Joissain tapauksissa saatat käyttää jopa yhdistelmää näistä kahdesta tyylistä samassa järjestelmässä vastaamaan eri osien tarpeisiin.
Siirretään huomiomme pois näistä turhista väittelyistä ja keskitytään suunnittelemaan todella erinomaisia API:a. Loppujen lopuksi teknologia on tarkoitettu ongelmien ratkaisemiseen, ei niiden luomiseen.