Rakennusliittymän toiminnallisuus
Minulla ei ole paljon kokemusta API:iden luomisesta. Olen tehnyt melkoisen osan työstä WordPressin integroinnissa kolmansien osapuolien sovellusliittymiin, mutta olen käyttänyt hyvin vähän aikaa sellaisen järjestelmän luomiseen, jossa on API, jonka kanssa muut järjestelmät voivat olla vuorovaikutuksessa.
Mitä tulee jälkimmäiseen, olen itse asiassa tekemässä sitä (ja opin paljon). Projektin ydin on iOS-sovellus, joka on vuorovaikutuksessa WordPressin kanssa REST API :n kautta kaksisuuntaisella tavalla.
Haluan kertoa siitä lisää, mutta minun on tehtävä se, kun projekti etenee.
Mutta kun tulee työskennellä kolmannen osapuolen sovellusliittymien kanssa ja sitten rakentaa WordPress-projektin komponentteja, jotka ovat vuorovaikutuksessa niiden kanssa, kaksi niistä asioista, joita pidän jatkuvasti hyödyllisinä, ovat:
- käyttämällä oikeaa kirjastoa ,
- järjestelmän kaaviokuvaus,
- jakaa toiminnot osiin.
Ja kaksi viimeistä yllä olevaa kohtaa ovat mitä yritän kattaa tässä viestissä.
Rakennusliittymän toiminnallisuus
Tähän viestiin ei sisälly koodia, mutta ehkä se on opas kuinka voit edetä työssäsi API-toimintojen jäsentämisen tai vastaavan tekemisen kanssa.
Kolmannen osapuolen kirjastot
Mainitsen tämän vain siksi, että mielestäni on arvokasta käyttää uudelleen kokeiltuja ja oikeita ratkaisuja, joita on testattu (ja siten käytetty) kautta linjan erilaisissa projekteissa.
Guzzle on suosikkikirjastoni. Kyllä, WordPressissä on sisäänrakennettuja toimintoja viestimiseen muiden URL-osoitteiden kanssa, mutta voit tehdä enemmän Guzzlella (etenkin mitä tulee pyynnön osiin) kuin WordPressillä.
Myönnetään, tämä on minun mielipiteeni, mutta nautin sen kanssa työskentelystä. Ja dokumentaatio on vankka.
Järjestelmän kaavio
Kun työskentelet integroinnin kanssa kolmannen osapuolen sovellusliittymien kanssa riittävän pitkään, sinun on totuttava järjestelmän toiminnan määrittämisprosessiin. Yleensä se menee jotenkin näin:
- luo API-asiakassovellusliittymään yhdistämistä varten,
- määritä tarvittavat toiminnot tarvitsemiesi pyyntöjen tekemiseen,
- jäsentää vastaus,
- palauttaa sen alkuperäiseen objektiin tai funktioon, joka kutsui pyynnön.
Tämä on hieman liiallista yksinkertaistamista (API-asiakkaan luominen voi loppujen lopuksi olla tehtävä sinänsä), mutta pisteet pysyvät kaikki samoina (eikä välttämättä tee huonoa sarjaa 🤔).
Joka tapauksessa ennen kaikkea järjestelmän kaavioista ei ole koskaan haittaa. Teen tätä edelleen, koska se auttaa minua tietyssä mielessä artikuloimaan, mitä olen rakentamassa, ja katsomaan, onko sovelluksen läpi kulkevassa hallinnassa aukkoja.
Tästä syystä, ellei muusta syystä, tämä on tärkeää: Asioiden artikulointi auttaa sinua ymmärtämään, mitä olet tekemässä, ja paljastaa usein ajattelussasi aukkoja, joita pidät itsestäänselvyytenä.
Joten kun on kyse järjestelmän laatimisesta, älä oleta, että olet selvittänyt kaiken.
Toiminnan erottaminen
Jos olet lukenut tätä blogia pidemmän aikaa, tiedät, että seuraan koko "huolenaiheiden erottelu" -kehitysideoita.
Tämä on totta useista syistä, joista vähiten eivät ole:
- kyky testata API-asiakasta erillään,
- pitää koodin kommunikointia varten käyttöliittymän ja taustan kanssa itsenäisenä.
Kun sinulla on luokka, joka on omistettu liikelogiikan ajamiseen arvojen päällä, voit siirtää suuren osan virheiden käsittelystä väliluokkaan.
Tämä tarkoittaa, että suurimmasta osasta liiketoimintalogiikasta vastaavalla ydinluokalla tulisi olla juuri se, mitä se tarvitsee työnsä suorittamiseen. Tämä ei tarkoita sitä, etteikö virheentarkistusta ei pitäisi tehdä (jako nollalla tai jotain, tiedätkö?), mutta se tarkoittaa, että tiedot voidaan tarkistaa ennen kuin se edes pääsee ydinluokkaan väliluokan kautta.
Se ei vain voi tarkistaa puuttuvien tietojen varalta, vaan se voi myös ilmoittaa nämä virheet takaisin käyttöliittymälle.
Kolme muistettavaa seikkaa
Jos olet luomassa Ajax-pohjaista järjestelmää WordPressissä, kaikella on kolme pointtia:
- kaavio luomastasi järjestelmästä,
- luoda väliluokka puuttuvien tietojen käsittelemiseksi ja raportoida virheistä,
- Lähetä täydelliset tiedot ydinliiketoimintaluokkaan vasta, kun kaikki tiedot on varmistettu.
Kun olet tehnyt sen, tavoitteena olisi saada ydinliiketoimintaluokka palauttamaan pyydetyt arvot ilman virhettä, koska ne on saatu kiinni ennen kuin ne ovat saavuttaneet sen.