Mul ei ole API-de loomisel palju kogemusi. Olen teinud suure osa tööst WordPressi integreerimisel kolmandate osapoolte API-dega, kuid olen kulutanud väga vähe aega süsteemi loomisele, millel on oma API, millega teised süsteemid saaksid suhelda.
Mis viimasesse puutub, siis ma tegelikult tegelen sellega (ja ma õpin palju). Projekti põhiolemus seisneb selles, et seal on iOS-i rakendus, mis suhtleb WordPressiga REST API kaudu kahesuunaliselt.
Ma tahan sellest rohkem rääkida, kuid pean seda tegema, kui projekt on kaugemal.
Kui aga rääkida kolmandate osapoolte API-dega töötamisest ja seejärel nendega suhtlevate WordPressi projekti komponentide loomisest, on kaks asja, mis mulle pidevalt kasulikud on:
- kasutades korralikku raamatukogu ,
- süsteemi diagrammi koostamine,
- funktsioonide jagamine osadeks.
Ja kaks viimast ülaltoodud punkti on need, mida ma selles postituses käsitlen.
API funktsionaalsuse struktureerimine
See postitus ei sisalda koodi, kuid võib-olla on see juhend selle kohta, kuidas saate API funktsionaalsuse struktureerimise või midagi sarnast oma töös edasi liikuda.
Kolmandate osapoolte raamatukogud
Mainin seda ainult seetõttu, et minu arvates on kasulik uuesti kasutada proovitud ja tõelisi lahendusi, mida on erinevates projektides testitud (ja seega kasutatud).
Guzzle on minu valitud raamatukogu. Jah, WordPressil on sisseehitatud funktsioonid teiste URL-idega suhtlemiseks, kuid Guzzle’iga (eriti mis puudutab päringu komponente) saate teha rohkem kui WordPressiga.
Tõsi, see on minu arvamus, kuid mulle meeldib sellega töötada. Ja dokumentatsioon on korralik.
Süsteemi diagrammi koostamine
Kui töötate piisavalt kaua kolmanda osapoole API-dega integreerimisega, peate süsteemi toimimise seadistamise protsessiga harjuma. Tavaliselt läheb see umbes nii:
- luua API-klient API-ga ühenduse loomiseks,
- seadistage vajalike päringute tegemiseks vajalikud funktsioonid,
- analüüsi vastust,
- tagastab selle päringu käivitanud algsele objektile või funktsioonile.
See on pisut ülelihtsustatud (lõppude lõpuks võib API kliendi loomine olla ülesanne omaette), kuid punktid jäävad kõik samaks (ja ei pruugi olla halb seeria 🤔).
Igatahes, ennekõike ei tee süsteemi diagrammi koostamine kunagi paha. Seda ma ikka teen, sest see aitab mul teatud mõttes sõnastada, mida ma loon, ja näha, kas rakenduse kaudu toimuvas juhtimises on lünki.
Siin on põhjus, miks, kui mitte mingit muud põhjust, on see oluline. Tegevuse sõnastamine aitab teil mõista, mida teete, ja paljastab sageli teie mõtlemises lünki, mida peate iseenesestmõistetavaks.
Seega, kui tegemist on süsteemi loomisega, siis ärge eeldage, et olete selle kõik välja mõelnud.
Funktsionaalsuse eraldamine
Kui olete seda ajaveebi mõnda aega lugenud, siis teate, et ma fännan kõiki "murede eraldamise" arendusideid.
See kehtib mitmel põhjusel, millest vähim ei ole:
- võimalus API klienti eraldi katsetada,
- esi- ja tagaosaga suhtlemise koodi sõltumatuna hoidmine.
Kui teil on klass, mis on pühendatud väärtuste äriloogika käitamisele, saate suure osa veakäsitlusest laadida vahepealsesse klassi.
See tähendab, et suurema osa äriloogika eest vastutaval tuumikklassil peaks olema täpselt see, mida ta oma tööks vajab. See ei tähenda, et vigade kontrollimine ei peaks olema paigas (nulliga jagamine või midagi muud, kas tead?), kuid see tähendab, et andmeid saab kontrollida enne, kui need vaheklassi kaudu tuumklassi jõuavad.
Ja see mitte ainult ei saa kontrollida puuduvat teavet, vaid saab ka nendest vigadest esiotsa tagasi teatada.
Kolm punkti, mida meeles pidada
Kui loote WordPressis Ajaxile tugineva süsteemi, on sellel kõigel kolm mõtet:
- joonistage loodava süsteemi skeem,
- looge vaheklass puuduva teabe käsitlemiseks ja teatage vigadest,
- Saatke kogu teave põhiäriklassile alles pärast kogu teabe kontrollimist.
Kui olete seda teinud, oleks eesmärk, et põhiäriklass tagastaks nõutud väärtused vigadeta, kuna need tabatakse enne selleni jõudmist.