Üks parimaid viise oma staatuse tõstmiseks a WordPressi arendaja , vähemalt teie klientide silmis, peab saama API-de tarbimise oskuslikuks. Siin on WordPressi API juurutamise levinud stsenaarium: teie klient palub teil oma saidile vidina lisada - näiteks öelda e-posti tellimuse vidin. Haarate nende kolmanda osapoole e-posti teenusest mõne koodi - võib-olla on see skripti silt või iframe - kleepige see lehele ja vastate oma kliendile: 'Sain aru!'

Kahjuks on teil tegemist pisut nõudlikuma kliendiga ja nad märkavad järgmisi puudusi:

• Kuigi vidinal on sarnaselt ülejäänud saidile ka font sans-serif, pole see päris õige. Vidin kasutab teie installitud kohandatud fondi asemel Helveticat.
• Vidina tellimisvorm käivitab uue lehe laadimise, mis võib artikli keskel asetades olla häiriv.
• Tundub, et vidin võtab pärast ülejäänud lehte laadimiseks lisamomendi, mis tundub ebareaalne ja odav.
• Klient soovib, et tellijad saaksid märgitud metaandmetega, lähtudes postitusest, mille nad tellisid, ja vidin ei paku midagi selle funktsionaalsusega kaugelt sarnast.
• Kliendi arvates on tüütu, et nad peavad nüüd haldama kahte juhtpaneeli (e-posti teenuse wp-admin ja administraatori ala).

Siinkohal võib mõistlikult juhtuda üks kahest. Võite kuulutada need üksused meeldivateks ja kinnitada oma klientidele selle eeliseid 80/20 lahendus või võite need taotlused täita. Oma isikliku kogemuse põhjal olen leidnud, et selliste taotluste täitmine - see tähendab kolmandate osapoolte teenuste valdamise demonstreerimine - on usaldusväärne viis veenda klienti, et olete omamoodi WordPressi viisard. Lisaks on seda sageli tore teha.

Viimase kümne aasta jooksul olen kasutanud WordPressi kui API tarbimise platvormi tõenäoliselt 50 erineva API-ga võrreldes. Mõned kõige levinumad API-d on olnud MailChimp, Google Analytics, Google Maps, CloudFlare ja Bitbucket. Aga mis siis, kui peate tegema rohkem, mis siis, kui vajate kohandatud lahendust?

Kuidas arendada WordPressi API klienti

Selles artiklis töötan välja üldise e-posti teenuse API abil, püüdes anda endast kõik, et asjad oleksid võimalikult agnostilised. Siiski arvan, et on mõistlik eeldada, et tegemist on JSON REST API-ga. Siin on mõned taustateemad, mis võivad aidata teil selle artikli tehnilisi punkte nautida:

• WordPress HTTP funktsioonide perekond
• JSON
• Puhkus

Kui leiate, et olete nende teemadega veidi tuttav ja olete huvitatud süvenemisest, tehke kohe paus ja laadige alla suurepärane Postimees rakendus. See võimaldab teil API-dega suhelda ilma koodi kirjutamata.

Postimees. Võib-olla minu lemmik arendusvahend?

Kui te pole aga nendega üldse tuttav, jätkake ikkagi lugemist. Tehniline vaatajaskond, kellel on WordPressi teatud määral kogemusi, saab sellest artiklist maksimumi, kuid ma hoolitsen selle eest väärtus iga tehnika vähem tehnilisel viisil. Mittetehniline lugeja jätab selle artikli hindama iga punkti ROI-d enne selle sponsoreerimist ja hindama rakendamise kvaliteeti pärast selle edastamist.

Märge: Kui vajate kiiret täienduskursust, saate tutvuda meie lehega WordPressi REST API juhend .

Ilma pikema preambulita lubage mul jagada teiega käputäis erinevaid tehnikaid, mida hindan kõige enam igas API-s, projektis ja meeskonnas, kellega ma töötan.

Mööduvad ajad: millal neid hoida, millal neid klappida

Oma avapunktis märkisin, et kliendil oli tüütu kahes administraatoripiirkonnas ringi liikuda: wp-admin ja oma e-posti teenuse juhtpaneel. Hea viis selle lahendamiseks oleks pakkuda neile juhtpaneeli vidinat wp-adminis, et näidata kokkuvõtet nende hiljutisest tellija tegevusest.

Näide armatuurlaua kasutajaliidese tüübist, mille võime pakkuda WordPressis, et salvestada klientidele reis nende kolmanda osapoole e-posti teenuse pakkuja juurde.

Kuid jällegi võib see nõuda mitu HTTP-päringut kaug-API-le (e-posti teenuse pakutav API), mille tulemuseks on pikk lehtede laadimine. Selle jõudlusprobleemi lahenduseks on API-kõnede salvestamine transientidena. See Koodeksi artikkel annab suurepärase selgituse, mida peaksite kindlasti lugema, kuid võtan selle kokku nii:

1. Hankige andmed kaug-API-st.
2. Hoidke seda, kasutades set_transient() aegumisajaga, mille valisite, lähtudes teie enda hinnangust toimivuse, kiirusepiirangute ja veavarale aegunud andmete kuvamisel selles konkreetses rakenduses.
3. Jätkake oma äriloogika järgi - töötlege andmeid, tagastage väärtus, olenemata juhtumist.
4. Kui vajate uuesti andmeid, näiteks järgmisel lehelaadimisel, kontrollige neid ajutises vahemälus, kasutades get_transient() enne kui järeldate, et peate selle saama API-st.

Pean seda abivalmis ja elujõuliseks vundamendiks, kuid võite selle sammu edasi teha, kui mõtlete hetkeks REST-i tegusõnade peale. Viiest levinumast meetodist (GET, POST, PATCH, PUT, DELETE) kuulub teie mööduvasse vahemällu ainult üks neist. Kas oskate arvata, kumb? See on GET. Pistikprogrammides on mul peaaegu alati PHP-klass, mis on pühendatud kõnesid abstraktsele kõnesolevale kaug-API-le, ja argument selle klassi instantiseerimisel on HTTP-meetod. Kui see pole GET-kõne, ei hakka ma üldse ühtegi vahemälu kihti kutsuma.

Veelgi enam, kui see pole GET-kõne, on mõistlik, et ma võtan mõne toimingu kaugandmete mingil moel muutmiseks, võib-olla lisades, muutes või eemaldades e-posti abonendi. See võib olla sobiv aeg selle ressursi olemasoleva vahemälu kehtetuks muutmiseks delete_transient() kaudu.

WordPressi e-posti tellimise API näite juurde naasmiseks toimige järgmiselt.

• Juhtpaneeli vidin hiljutiste abonentide kuvamiseks kutsub välja API lõpp-punkti /subscribers GET-päringu kaudu. Kuna see on GET-päring, salvestatakse see minu ajutisse vahemällu.
• E-posti loendi tellimiseks mõeldud külgriba vidin kutsub välja API lõpp-punkti /subscribers jaoks POST-päringu kaudu. Kuna see on POST-taotlus, mitte ainult see, et see väldib minu ajutist vahemälu, vaid kutsub mind üles kustutama oma ajutise vahemälu asjakohase osa, nii et armatuurlaua vidin kajastaks seda uut tellijat.
• Transientide nimetamisel korrastan neid sageli, nimetades need sõna otseses mõttes kaug-API URL-i järgi, mida kutsun. See on mugav viis kustutatava õige mööduva tuvastamiseks. Kui see on argument, mis liitub lõpp-punktiga, liidan need stringiks ja lisan need ka ajutisele nimele.

Kliendi või muu vähem tehnilise sidusrühmana peaksite alati taotlema ajutist vahemällu salvestamist - või vähemalt selle arutelu - iga kord, kui rakendus tõmbab andmeid kaugteenusest. Peaksite end suurepärasega kurssi viima Päringu jälgimine pistikprogramm, et saada ülevaade transientide toimimisest. See annab teile liidese sirvimiseks, milliseid andmeid ajutiselt, kui sageli ja kui kaua on peidetud.

Mõnikord pole transientidest piisavalt palju

Mõni esmaklassiline WordPressi hostimisteenus ei võimalda tegelikult tootmises transiente kasutada. Neil töötab kood, võib-olla MU pistikprogrammi või mõne muu skripti kujul, mis katkestab teie katse kasutada transientide API-d ja salvestab selle teabe objekti vahemälu selle asemel. WP-mootor , selle kõige tavalisemas konfiguratsioonis, on selle suurepärane näide.

Murettekitav vaatepilt phpMyAdmini kasutajaliideses: kas tootmiskoht puudub täielikult transientidest? Tõenäoliselt tähendab see, et objekti vahemälu töötab.

Kui lihtsalt salvestate ja hankite andmeid, ei pea te sellest tegelikult hoolima ega pruugi kunagi märganudki, et see toimub. Kogu *_transient() perekond funktsioonid pakuvad teile sama lõpptulemust, lihtsalt filtreeritud, et kasutada ajutist vahemälu asemel objekti vahemälu. Transiidide kustutamise katse võib siiski tekkida probleemides. Siin on põhjus.

Kui teie API-liidese integreerimine on piisavalt keeruline, et oma seadete leht ära teenida, võiksite lisada kasutajaliidese, et administraatori kasutaja saaks tühjendage pistikprogrammi kogu ajutine vahemälu . Selle nupu kõige tavalisem kasutamine on siis, kui klient muudab mõnda teavet otse kaugteenuses ja soovib kehtetuks muuta vahemälu, mille me WordPressi salvestame. See nupp võib olla kasulik ka siis, kui klient muudab konto mandaate, API-võtmeid või lihtsalt silumisnupuna “tehase lähtestamine”.

Kasutajaliidese näide, mis lubab kliendil oma API andmete jaoks kohaliku vahemälu tühjendada.

Isegi kui te oleksite piisavalt nutikas, et saaksite kõigi oma siirdevõtmete nimeruumi, nii et teil on lootust igaüks neist delete_transient() jaoks tuvastada, on parimal juhul tõenäoliselt siiski toores SQL, mida üritan WordPressis alati vältida :

get_transient_prefix() ); $options = $wpdb -> options; $t = esc_sql( '_transient_timeout_$prefix%' ); $sql = $wpdb -> prepare ( ' SELECT option_name FROM $options WHERE option_name LIKE '%s' ', $t ); $transients = $wpdb -> get_col( $sql ); // For each transient... foreach( $transients as $transient ) { // Strip away the WordPress prefix in order to arrive at the transient key. $key = str_replace( '_transient_timeout_', '', $transient ); // Now that we have the key, use WordPress core to the delete the transient. delete_transient( $key ); } } ?>

Pole mugav, mitte tõhus. Selle olukorra tõttu on vaja objekti vahemällu salvestamist kuna objektide vahemällu salvestamine annab meile mugava võimaluse vahemällu salvestatud väärtuste grupeerimiseks . Sel juhul, kui peate tühjendama kõik oma pistikprogrammiga seotud vahemälu väärtused, on see lihtne ühe liiniga kõne wp_cache_delete( $key, $group )

Ma võtaksin selle kõige kokku öeldes: Te ei saa olla API-de tarbimise ekspert, kui te pole veel nende andmete vahemälu haldamise ekspert.

Kliendina on peamine asi, mida tasub jälgida, vahemälu käitumine lavastus- ja tootmiskeskkondade vahel. Teisisõnu, kuigi uue partii katsetamine lavastuses on alati hea tava, on vahemällu salvestamine midagi, mida tuleb ka tootmises võrdse hoolega testida.

Kaug-API aitab teie PHP-klassi hierarhiat teavitada

Pistikprogrammi jaoks erinevate PHP-klasside koostamisel on mul sageli kasulik jäljendada API lõpp-punktide määratlust - näiteks mis näib olevat ühine järgmistel lõpp-punktidel?

• https://api.example-email-service.com/v1/subscribers.json
• https://api.example-email-service.com/v1/lists.json
• https://api.example-email-service.com/v1/campaigns.json

Nad kõik tulevad tagasi kollektsioonid , mille all mõtlen GET-päringu tulemust, tagastades tulemuse nullist paljudeni, kus iga tulemus on massiivi liige. See võib tunduda üsna ilmne, kuid minu arvates on see kasulik viide järgmise klassi struktuuri jaoks minu PHP-koodis:

• class.collection.php, abstraktne klass
• class.subscribers.php laiendab abstraktset klassi, Collection.
• class.lists.php laiendab abstraktset klassi, Collection.
• class.campaigns.php laiendab abstraktset klassi, Collection.

Abstraktne klass võtaks ainsaks argumendiks päringuparameetrite massiivi: sellised asjad nagu lehitsemine, veeru sortimine, järjestusjärjestus ja otsingufiltrid. Sellel oleks meetodeid tavaliste ülesannete jaoks, näiteks kaug-API kutsumine, vigade käitlemine ja tulemuste morfiseerimine HTML-i menüüsse või jQueryUI AutoSuggest. Klassid, mis eksponeerivad abstraktset klassi, võivad olla üsna lühikesed, tehes võib-olla vähe enamat, kui täpsustada string, mida selles kasutada *.json API lõpp-punkti URL.

Mailchimp avaldab API 'mänguväljaku' liivakasti API kõnede ja muu sellise jaoks. See toimib ka mugava viisina sirvida kogu nende API andmehierarhias, andes meile kasuliku pilgu sellest, kuidas saaksime oma klassi hierarhiat üles ehitada.

Samamoodi on ühist järgmistel lõpp-punktidel?

• https://api.example-email-service.com/v1/subscribers/104abyh4.json
• https://api.example-email-service.com/v1/lists/837dy1h2.json
• https://api.example-email-service.com/v1/campaigns/9i8udr43.json

Nad kõik tagastavad üksus , mille all mõtlen täpselt ühte konkreetset, ainulaadset kogu liiget: näiteks ühte kindlat e-posti tellijat, ühte e-posti loendit või ühte e-posti kampaaniat. Seetõttu meeldib mulle oma PHP-koodis kasutada järgmist struktuuri:

• class.item.php, abstraktne klass
• class.subscriber.php laiendab abstraktset klassi, Item.
• class.list.php laiendab abstraktset klassi, Item.
• class.campaign.php laiendab abstraktset klassi, Item.

Abstraktne klass võtaks ainsaks argumendiks stringi konkreetse taotletava üksuse tuvastamiseks. Taas võivad instantsitavad klassid olla üsna lühikesed, tehes võib-olla vähe enamat kui stringi määramine, mida */duy736td.json -is kasutada.

Klasside pärimise struktureerimiseks on palju lähenemisviise, kuid isegi kui lähenete sellele, mida ma eespool kirjeldasin, lähenete teisiti, vean kihla, et on suur tõenäosus, et kaug-API struktuur võib teie rakenduse struktuuri teavitada.

Kliendina on halva arhitektuuri levinud sümptom see, kui leiate, et peate rakenduses sama muutust taotlema. Näiteks kui soovite, et aruanded tagastaksid 100 tulemuse lehe kohta 10 asemel, ja peate seda taotlust tellijate aruannete, kampaaniaaruannete, tellimusest loobumise aruannete jms kohta kordama, võite avastada halva klassi arhitektuuri. Sellises olukorras tasub oma meeskonnalt küsida, kas neil oleks refaktoreerimistsüklist kasu: töö, mille eesmärk ei ole toote käitumise muutmine, vaid selle aluseks oleva koodi parandamine, et käitumist oleks lihtsam muuta toote tulevikus.

Ideaalne kasutuskott WP_Error jaoks

Mul on piinlik tunnistada, et mul kulus aastaid kauem, kui see peaks olema, et seda õigesti kasutama hakata WP_Error funktsioonide perekond minu koodis. Ma kippusin lihtsalt oma viisid kodeerima, eeldades, et kunagi pole vigu, mis tasuks programmeeritud eest hoolitseda, või käsitlen neid juhtumeid eraldi. Kaug-API-dega töötamine lõikab selle mentaliteedi läbi nagu laserkiir, sest see on ülimugav ja võimas kasutusvõimalus WP_Error kasutamiseks.

Meenutame varem, et mainisin, et mul on sageli PHP-klass, mille eesmärk on HTTP-taotluste esitamine kaug-API-le. Kui eemaldate kogu katla, kogu andmetega manipuleerimise ja kõik teisejärgulised probleemid, taandub see klass tõesti wp_remote_request() et saada API-lt HTTP-vastuse objekt. Mugavalt wp_remote_request() tagastab selle asemel WP_Error kui kõne ei õnnestu mingil põhjusel täita, aga mis saab siis, kui kõne õnnestub tagastada ebasoodsat tüüpi HTTP-vastus?

Tehniliselt öeldes API kõne töötas , kuid see pole täpselt vaba hoiatustest. Need hoiatused tuleb kogu koodibaasis lüüa ja neist järjepidevalt teavitada.

Näiteks võib-olla helistasime /lists.json lõpp-punkt, kuid sellel konkreetsel kontol pole veel ühtegi loendit seadistatud. See tagastaks kehtiva HTTP-vastuse, kuid olekukoodiga 400. Kuigi see pole just iseenesest saatuslik tõrge, võib mõne kasutajaliidese koodi vaatenurgast, mis soovib selle API-kõne muuta rippmenüüks, 400 samuti olla a WSOD ! Seetõttu on minu arvates kasulik teha wp_remote_request() tulemusele täiendav sõelumine, tagastades potentsiaalselt WP_Error Pealegi:

url, $this -> args ); $code = wp_remote_retrieve_response_code( $response ); $first_digit = $code[0]; $good_responses = array( 2, 3 ); if( ! in_array( $first_digit, $good_responses ) { $body = wp_remote_retrieve_body( $response ); $out = new WP_Error( $code, $body ); } else { $out = $response; } return $out; } ?>

See muster aitab lihtsustada koodi, mis kutsub meie helistajaklassi, sest teame, et saame is_wp_error() enne meie väljundiga jätkamist.

Kliendina peaksite aeg-ajalt mängima pahatahtliku kasutaja, segaduses oleva kasutaja ja kannatamatu kasutaja rolli. Kasutage rakendust viisil, mida seda ei olnud mõeldud kasutamiseks. Tehke asju, mida teie arendajad ei soovi, et te teeksite. Pange tähele, mis juhtub. Kas saate kasulikke veateateid? Kas saate üldse veateateid? Kui ei, siis võib olla väärt spetsifitseerida tööd parema veakäsitluse nimel.

ob_get_clean() Ilus silumisjõud

Kaasaegsest programmeeritavast veebist, kus peaaegu iga sait tarbib teiste saitide API-sid ja mida tarbitakse ise oma API kaudu, on saanud koodi jaoks uskumatult võimas areen. Kuid just see kvaliteet võib ka selle üsna aeglaseks muuta.

On tavaline, et HTTP kaug päringud on antud lehe laadimise kõige aeganõudvamad osad. Sel põhjusel käivitavad paljud API-põhised komponendid kas Ajaxi või croni kaudu. Näiteks peaks e-posti abonentide loendi kaudu otsimiseks mõeldud automaatne soovitus ilmselt iga klahvivajutuse korral pingutama kaugandmete allikat nõudmisel, selle asemel, et lehe laadimisel laadida DOM-is kõik 100 000 tellijat. Kui see pole valik, võib võib-olla suur päring sünkroonida öises croni ülesandes, nii et tulemusi saab hankida kohalikust peeglist, mitte kaug-API-st.

Selle lähenemisviisi probleem seisneb selles, et silumist võib olla keeruline teha. Selle asemel, et lihtsalt sisse lülitada WP_DEBUG ja lasete tõrketeadetel oma brauseriaknasse veereda, olete brauseri võrgukonsoolist vaadates kinni jäänud või logifaili sepistamine croni ülesandena (loodetavasti?) täidab. Minu arvates on see ebamugav.

Üks võimalus olukorra parandamiseks on ettevaatlik ja strateegiline üleskutse error_log() . Kuid jällegi on logimise tavaline probleem see, et suurte või hõivatud rakenduste korral võivad vikalogid kasvada liiga suureks või kasvada liiga kiiresti, et olla jälgimiseks või sõelumiseks kasulik. Seetõttu peame olema sisselogitavate suhtes valikulised, panustades sellele sama palju mõtteid, nagu me teeme oma tegeliku rakendusloogikaga . Kahju, et leidsite aega eksootilise servajuhtumi vea registreerimiseks, mis näib esinevat katkendlikult mõne harvaesineva croni ülesande korral ainult selleks, et mõista, et vea tõeline olemus on teid jälle kõrvale hoidnud, kuna te ei suutnud mõnda konkreetset massiivi liiget sisse logida , ütleme, rikkuva väärtuse kohta.

Seetõttu on minu filosoofia muutunud Ma ei logi alati sisse, aga kui login, siis login kõik sisse . Teisisõnu, pärast eriti murettekitava funktsiooni tuvastamist login selle võimalikult laia võrguga:

var_dump()

See tähendab, et

|_+_|

‘kogu lollakasväärtuse ühendamine ühte tõrke logifaili kirjesse.

Veapäevik, mis on liiga suureks kasvanud, et silumiseks ergonoomiline olla.

Kliendina tasub perioodiliselt kontrollida kogu rakenduse failimälu kasutamist. Kui märkate, et hüppate järsku oma hostikonto talletusmahu piiresse, on suur tõenäosus, et selles on süüdi tõrke logi. Teie arendajatele on kasulik paremale metsaraiele keskendunud tötsükkel - ja teie kliendid saavad samuti!

Mitte just Clickbait, aga nii saab

Andestage palun selle artikli loendi ülesehitus. Ma ei suutnud sundida neid punkte ühendavamaks artikliteemaks, sest need mustrid on väga üldised: Need kehtivad mis tahes JSON REST-i lõpp-punkti ja kõigi WordPressi väljundite kohta .

Need on mustrid, mida näen esinevat üha uuesti, olenemata sellest, mis on kaug-API või milleks me seda WordPressis kasutame. Olen jõudnud nii kaugele, et olen kogunud kõik sellised põhimõtted pistikprogrammi katlaplaadile, mis kiirendab minu tööd oluliselt. Kas teil on sarnaseid punkte, mida iga projekti jaoks säilitate? Palun jagage neid, et saaksin neid varastada ja oma katlaplaadile lisada!

Seotud: Kuidas läheneda kaasaegsele WordPressi arendusele (1. osa)

Põhitõdede mõistmine

Mis on WordPressi REST API?

Mugav viis WordPressi kasutamiseks API avaldamiseks. Seda API-d saavad kasutada muud WordPressi saidid, muud saidid, mis pole WordPress, või isegi avaldamissait ise. See on populaarne lähenemisviis WordPressi kasutamiseks peata CMS-iga või isegi ainult väikesemahuliste Ajaxi kuulajate jaoks.

Mis on WordPressi API-võti?

API-võtmed on levinud viis autentimise haldamiseks. WordPressi API ühildub mitme autentimismeetodiga. Üks neist on WordPressi REST API OAuthi pistikprogramm, mis annab kasutajatele liidese API võtmete haldamiseks.

Mis on WP-JSON?

WP-JSONi võib pidada WordPressi RSS-i vaate vennaks koos tavalise esiotsa kuvaga. See on veel üks viis WordPressi andmete väljastamiseks, kuigi enamik inimlugejaid ei sooviks WordPressi selles vormingus tarbida. Selle eesmärk on pigem API klientide tarbimine.