WordPressin REST API näyttää ulospäin yksinkertaiselta: HTTP-pyyntö sisään, JSON-vastaus ulos. Todellisuudessa REST-pyyntö kulkee läpi pitkän ja monivaiheisen elinkaaren, joka on tiiviisti sidoksissa WordPressin bootstrap-prosessiin, hook-järjestelmään ja autentikointimekanismeihin.
Kun REST request lifecycle ymmärretään oikein, monet mystiset ongelmat – hitaat endpointit, väärät oikeudet, rikkoutuneet vastaukset – muuttuvat loogisiksi seurauksiksi arkkitehtuurista, ei satunnaisiksi bugeiksi.
REST-pyynnön sisääntulo
REST-pyyntö saapuu yleensä polkuun:
/wp-json/namespace/v1/endpoint
WordPress ohjaa tämän pyynnön sisäisesti index.php-tiedoston kautta, aivan kuten tavallisen frontend- tai admin-pyynnön. Tämä on ensimmäinen tärkeä havainto: REST-pyyntö bootstraappaa lähes koko WordPressin.
Tässä vaiheessa:
– wp-config.php ladataan
– tietokantayhteys alustetaan
– lisäosat ja teemat valmistellaan lataukseen
REST ei ole kevyt erillinen mikropalvelu, vaan osa samaa request lifecyclea.
Mu-plugins ja plugin-lataus
Ennen varsinaista REST-logiikkaa WordPress lataa:
– mu-plugins
– network-plugins (multisite)
– tavalliset lisäosat
Kaikki näissä oleva koodi ajetaan myös REST-pyynnöissä. Tämä on yksi yleisimmistä suorituskykyansoista: mu-plugin tai lisäosa tekee raskasta logiikkaa jokaisella pyynnöllä, vaikka REST-endpoint ei sitä tarvitsisi.
REST API -alustus
Kun WordPress ydin on alustettu, REST API aktivoituu:
– rest_api_init-hook ajetaan
– endpointit rekisteröidään
– namespace- ja reittimääritykset luetaan
Jos endpoint rekisteröidään liian myöhään tai väärässä hookissa, se ei koskaan vastaa.
Autentikointi ja oikeudet
Seuraavaksi WordPress käsittelee autentikoinnin. Tämä tapahtuu useassa kerroksessa:
– evästepohjainen autentikointi
– application passwords
– nonce-tarkistukset
– custom authentication handlers
Tärkeää on ymmärtää, että:
– autentikointi ei ole yksi vaihe
– permission callback ajetaan vasta endpointin yhteydessä
Monet virheet syntyvät, kun permission callback sisältää raskasta logiikkaa tai tietokantakyselyitä, jotka ajetaan jokaisella REST-pyynnöllä.
Requestin reititys
Kun autentikointi on kunnossa:
– URL matchataan rekisteröityyn reittiin
– HTTP-metodi tarkistetaan
– request-objekti luodaan
Tässä vaiheessa WordPress ei vielä ole ajanut varsinaista liiketoimintalogiikkaa. Se on vain varmistanut, että pyyntö saa mennä perille.
Callbackin suoritus
Endpointin callback on se kohta, jossa:
– sovelluslogiikka ajetaan
– tietokantakyselyt tehdään
– data haetaan ja muokataan
Tämä on lifecycle-vaihe, jossa suurin osa suorituskykyongelmista syntyy. Usein syynä on:
– WP_Query ilman rajoituksia
– meta-queryt ilman indeksejä
– ulkoiset HTTP-kutsut synkronisesti
REST ei tee näistä kevyempiä. Se vain kuljettaa ne JSONin läpi.
Response ja WP_Error
Callback palauttaa yleensä:
– taulukon
– WP_REST_Response-olion
– WP_Error-olion
WordPress:
– serialisoi datan JSONiksi
– asettaa HTTP-statuskoodin
– lisää REST-spesifit headerit
Jos palautetaan WP_Error, se muunnetaan automaattisesti virhevastausmuotoon. Tämä tekee virheenkäsittelystä yhtenäistä – jos sitä käytetään oikein.
Output buffering ja shutdown-vaihe
REST-pyynnön lopussa WordPress:
– flushaa output bufferit
– ajaa shutdown-hookit
– sulkee tietokantayhteydet
Jos joku lisäosa käyttää output bufferingia väärin tai tulostaa dataa suoraan, REST-vastaus voi rikkoutua täysin.
Suorituskykyvaikutukset kokonaisuutena
REST request lifecycle tarkoittaa käytännössä:
– lähes täysi WordPress-boot jokaiselle pyynnölle
– kaikkien pluginien koodin lataus
– monikerroksinen hook-järjestelmä
Tämä tekee REST API:sta:
– joustavan
– laajennettavan
– mutta ei kevyen
Large-scale-ympäristöissä tämä näkyy CPU-kuormana ja hitaana vasteaikana.
Yleiset sudenkuopat
– endpointit rekisteröidään väärässä hookissa
– permission callback tekee liikaa työtä
– mu-plugins sisältää frontend-logiikkaa
– REST-pyyntöjä ei erotella frontend-pyynnöistä
– cache-strategia puuttuu kokonaan
Yhteenveto
WordPressin REST request lifecycle on tiukasti sidoksissa koko WordPressin arkkitehtuuriin. REST ei ohita corea, vaan kulkee sen läpi. Tämä tuo:
– yhtenäisen kehitysmallin
– vahvan autentikoinnin
– laajennettavuuden hookeilla
Samalla se tuo:
– suorituskykykustannuksia
– monimutkaisen elinkaaren
– ylläpidon haasteita
Kun lifecycle ymmärretään kokonaisuutena, REST-endpointit voidaan rakentaa kevyiksi, ennustettaviksi ja skaalautuviksi. Ilman tätä ymmärrystä REST API:sta tulee helposti vain toinen tapa tehdä samoja hitaita asioita JSON-muodossa.
