Share
Med begynnelsen i 2003 har WordPress vokst opp fra bare en blogging-plattform til et fullverdig innholdssystem. I løpet av de siste årene har den blitt modnet nok til å imøtekomme behovet for det store flertallet av online publikum, og dette er grunnen til at det gir mer enn 20% av nettet i dag.
Med mange nye funksjoner som blir lagt til i WordPress, er en av de nyeste til-være-tilleggene REST API som tillater andre apper og plattformer å samhandle med WordPress. Det er et revolusjonerende tillegg som hjelper utviklere å bygge tilpassede applikasjoner og integrerte systemer med WordPress. Siden det gir mulighet til å legge til og hente innhold fra en annen klient eller et nettsted, uten at det er nødvendig å ha WordPress på dette nettstedet, kan WordPress brukes til alle programmeringsspråk eller plattformer.
I denne flerpartiserien tar vi en titt på WP REST API og hvordan den kan brukes til å skape brukeropplevelser som ellers var umulige eller i det minste vanskelige med WordPress. Vi vil først ta en titt på grunnleggende begreper, inkludert REST og JSON, og undersøk deretter de tilgjengelige alternativene for oss gjennom WP REST API.
Nedenfor er noen ressurser som jeg fant nyttig for grunnleggende konsepter, inkludert HTTP, REST og JSON. Jeg anbefaler deg å ta en titt på dem hvis du ikke allerede har:
Før vi begynner med vårt emne, la oss få en kort titt på hva som faktisk er REST-arkitekturen og også bli kjent med sin vanlige terminologi.
For å starte med emnet, la oss ta en titt på REST (Representasjons State Transfer) arkitektur og noen av de mest vanlige konseptene. Å forstå dem er viktig når du utvikler programmer som bruker REST arkitektonisk stil.
REST er en arkitektonisk stil som bidrar til å skape og organisere et distribuert system. Den beskriver Internett som et distribuert hypermedia-program, hvis koblede ressurser kommuniserer ved å utveksle representasjoner av ressurs stat.
Ressurser er hovedbygningene i REST-arkitekturen. Faktisk er de hovedblokkene på nettet selv i den grad at nettet noen ganger refereres til som "ressursorientert".
Når du snakker om WordPress, er disse ressursene diskrete enheter som innlegg, sider, kommentarer, brukere og tilpassede innleggstyper etc. Å samhandle med ressurser, URI (Uniform Resource Identifier) brukes, og som navnet antyder, er det en identifikator for en ressurs.
En RESTful tjeneste behandler URIer som den primære måten å adressere en underliggende ressurs på. Disse ressursene kan ha flere representasjoner. For eksempel kan en bildefil være tilgjengelig i .JPG-, .GIF- eller .PNG-formater. Forholdet mellom ressurser og URIer er en til mange. En URI kan bare peke på en bestemt ressurs, men en ressurs kan ha mer enn én URI.
Listen over alle ressursene som støttes av WP REST-APIen, er som følger:
Vi kan utføre forskjellige handlinger på disse ressursene ved hjelp av HTTP-verb.
En REST API gjør det i utgangspunktet mulig å utføre CRUD (Create Read Update Delete Delete) operasjoner på ressurser ved hjelp av HTTP. For dette formål bruker REST bruk av begrenset sett med HTTP-forespørselsverker som er som følger:
Accentsconagua
FÅ: Brukes til å lese eller hente en ressursPOST: Brukes til å opprette en ny ressursSETTE: Brukes til å oppdatere en ressursSLETT: Brukes til å slette en ressursHODE: Brukes til å sjekke om en ressurs eksisterer uten å returnere sin representasjonALTERNATIVER: Brukes til å hente alle verbene som støttes av en ressursI en RESTful tjeneste har disse verbet en veldefinert betydning. De første fire verbene i listen ovenfor er en del av CRUD-handlinger, dvs. de henter, lager, oppdaterer og sletter enheter. De to siste verbene hjelper en klient til å avgjøre om en ressurs eksisterer og hvilke HTTP-verker som er tilgjengelige for å utføre videre operasjoner.
EN FÅ forespørsel henter informasjon og er idempotent, dvs. en klient kan kalle det mange ganger, men det vil ikke påvirke tilstanden til en ressurs.
For å få alle innleggene ved hjelp av WP REST API, bruker vi følgende endepunkt:
GET wp / v2 / innlegg
Ovennevnte sluttpunkt vil returnere a samling av alle postenheter.
Når følgende endepunkt utløses, returnerer det et bestemt enhet dvs. et innlegg med et id på 100:
GET wp / v2 / innlegg / 100
EN POST forespørsel oppretter en ny enhet og a SETTE forespørsel erstatter den enheten med en ny versjon.
Følgende POST forespørsel kan brukes til å opprette et nytt innlegg (sender forespørselsorganet som vi skal se på i den senere delen av serien) ved hjelp av WP REST API:
POST wp / v2 / innlegg
Og følgende SETTE forespørsel vil oppdatere et innlegg med et ID på 100:
PUT wp / v2 / innlegg / 100
EN SLETT forespørsel sletter en ressurs fra systemet. Denne typen forespørsel, sammen med SETTE forespørsel er repeterbar, noe som betyr at det å kalle disse metodene vil ha samme effekt på systemet. For eksempel, hvis du ringer en SETTE Be om flere ganger på en ressurs (med samme argumenter), vil resultatet bli det samme. Det samme gjelder for a SLETT be om. Slette en ressurs flere ganger vil ha samme effekt, dvs. ressursen vil bli slettet (eller en feil ville bli returnert i tilfelle en allerede slettet ressurs).
I tillegg til disse CRUD-handlingene, gir en RESTful tjeneste to flere verker som er ALTERNATIVER og HODE. Disse verbene kommer til nytte når en klient må sjekke hvilke ressurser som er tilgjengelige på systemet og hvilke handlinger de støtter, og dermed gi en selvdokumenterende måte for klienten å videreutvikle systemet og utføre handlinger. Vi vil se disse to metodene i bruk senere i denne opplæringen.
Merk at i det aller første eksempelet ovenfor brukte vi følgende endepunkt:
GET wp / v2 / innlegg
Endpoints er funksjoner som er tilgjengelige via API, og de utfører flere handlinger som å hente innlegg (som vi gjør over), opprette en ny bruker, eller oppdatere et innleggsmetode. Alternativt kan vi si at et sluttpunkt utløser en metode som utfører en bestemt oppgave. Disse endepunktene er avhengige av HTTP-verbet som er tilknyttet dem. I eksemplet ovenfor bruker vi GET-verbet for å hente alle innlegg.
De rute for ovennevnte endepunkt er følgende:
AT / v2 / innlegg
En rute er i utgangspunktet et navn for å få tilgang til endepunktet. En rute kan ha flere endepunkter basert på HTTP-verb. Så den ovennevnte ruten har følgende endepunkt for å opprette et nytt innlegg:
POST wp / v2 / innlegg
Dette sluttpunktet, når det utløses med medfølgende parametere, vil skape en ny postenhet.
Vurder følgende rute:
wp / v2 / poster / 100
Denne ruten peker på Post-enheten som har et ID på 100. Den har følgende tre endepunkter:
GET wp / v2 / innlegg / 100: Som kan brukes til å hente innlegget som har et id på 100. Det utløser get_item () metode.PUT wp / v2 / innlegg / 100: Kan brukes til å oppdatere innlegget med et ID på 100. Det utløser update_item () metode.SLETT WP / V2 / innlegg / 100: Det sletter innlegget som har et ID på 100. Det utløser delete_item () metode.Vi vil lære mer om internettet til WP REST API, det er klassestruktur og interne metoder i den siste delen av denne serien.
La oss nå oppdatere vår kunnskap om noen vanlige HTTP-responskoder og hva de betyr.
En server svarer på en forespørsel ved å returnere et svar som inneholder en HTTP-statuskode. Disse kodene er tall med forhåndsdefinerte betydninger knyttet til dem. For eksempel vil alle som bruker nettet, være kjent med 404 statuskode som oppsummerer at ressursen, brukeren lette etter, ikke ble funnet.
Responsen fra serveren er også avhengig av hvilken type HTTP-verb eller metode vi bruker i forespørselen som sendes, som vi vil se neste.
Følgende er noen vanlige HTTP-responskoder sammen med deres betydninger, som vi vil møte når de arbeider med WP REST API og deres betydninger:
200 - OK: Betyr at forespørselen er fullført, og serveren har returnert svaret. Vanligvis returnert etter en vellykket FÅ be om.201 - Opprettet: Vanligvis returnert etter en vellykket POST be om. Oppsummerer at ressursen er opprettet.400 Ugyldig forespørsel: Den returneres fra serveren når en forespørsel ble sendt med noen manglende eller ugyldige parametere. Vanligvis returnert som svar på POST eller SETTE forespørsler.401 - Uautorisert: Betyr at brukeren ikke var autorisert til å utføre bestemte handlinger. For eksempel prøvde en bruker å opprette eller slette en ressurs uten å gi legitimasjonsinformasjon for godkjenning.403 Forbudt: Betyr at serveren forstod forespørselen, men nektet å fullføre den på grunn av godkjenning. Det skjer når en bruker oppgir godkjenningsopplysninger, men det har ikke tilstrekkelige rettigheter til å utføre handlingen.404 ikke funnet: Den mest kjente av alle statuskoder. Oppsummerer at en ressurs, som brukeren lette etter, ikke ble funnet.405 - Metode ikke tillatt: Betyr at et HTTP-verb som følger med i forespørselen, ikke ble støttet av ressursen. Et eksempel kan være en bruker som prøver å oppdatere en skrivebeskyttet ressurs.410 - Gone: Betyr at en ressurs har blitt flyttet til et annet sted. Et eksempel kan være å prøve å slette en allerede slettet ressurs som er flyttet til papirkurven.500 - Intern serverfeil: Den returneres når en server møter en uventet tilstand og ikke fullfører forespørselen.501 - Ikke implementert: Betyr at serveren ikke støtter funksjonaliteten for å fullføre forespørselen. Vanligvis oppstår når en server mottar en forespørselsmetode som den ikke gjenkjenner.Vi vil se nærmere på disse HTTP-verker og svarkoder når vi faktisk begynner å jobbe med APIen. Men før det, la oss ta en titt på årsakene til å bruke REST API med WordPress og fordelene det gir til både utvikleren og brukeren. Tross alt, jeg trenger deg til å være oppriktig interessert i å følge med meg i løpet av denne serien.
REST og JSON sammen gir en mekanisme for å lage kraftige applikasjoner ved hjelp av WordPress-back-end. De viktigste eksemplene er mobile apper som krever datautveksling mellom klienten (enheten) og serveren. Med sikte på båndbreddebegrensningene ved bruk av mobildata, gir JSON et lett alternativ til XML-baserte løsninger.
Siden JSON er et tekstbasert format for lagring av data, kan det brukes sømløst med de fleste programmeringsspråk. Derfor fungerer JSON som en global kontakt når du utveksler data mellom ulike plattformer som er like lesbare av både maskiner og mennesker.
Ved bruk av API som den som diskuteres, er innholdet på ditt WordPress-nettsted ikke begrenset til seg selv, men kan nås av andre nettsteder og klienter. Som API avslører noen deler av den interne funksjonaliteten, kan eksterne klienter samhandle med nettstedet ditt for å oppdatere eller opprette nytt innhold. Det tillater også å hente noe innhold fra et eksisterende WordPress-nettsted og vise det på et annet nettsted.
Med oppstart av JavaScript-rammer på klientsiden som Angular, Backbone eller Ember, har det nå blitt mulig å bruke en av disse til å skape riktige brukeropplevelser mens de fortsatt bruker WordPress back-end.
Med det sagt, er noen mulige brukstilfeller for WP REST API:
Det åpner virkelig opp en ny verden av muligheter hvor den eneste grensen er ens fantasi.
Forut for JSON-baserte REST-APIer, var API-en som ble brukt til å kommunisere eksternt med WordPress, XML-RPC API som fortsatt er en del av WordPress-kjerne. Problemet med XML er at det ikke er like lett som JSON-format, og dets analyse er ikke effektivt. Traversering av XML er også en stor av hodepine, mens kryptering av et JSON-objekt er like enkelt som å håndtere en innfødt JavaScript-objekt.
Det første REST API-pluginet som ble introdusert for WordPress var JSON API som ble utgitt i 2009. Det ble bygget på Museum of Modern Art for bloggen Inside / Out. Denne bloggens forside ble drevet av Ruby on Rails, for å hente innlegg fra og legge til kommentarer til WordPress-backenden, ble det utviklet en API. Dette plugin gir grensesnitt for å hente innhold og sende kommentarer til WP-backend. Selv om det ikke er oppdatert i mer enn to år, er dette pluginet fortsatt til stede i det offisielle depotet og er greit.
Bortsett fra plugin-modulen JSON API, har WordPress.com allerede gitt JSON API via JetPack plugin.
WP REST API, som vi kjenner det i dag, er en funksjonstillegg som ble foreslått av Ryan McCue som en del av GsoC (Google Summer of Code) 2013. Den er ennå ikke inkludert (helt) i WordPress-kjerne i en fremtidig utgave. Den nåværende versjon 2.0 av plugin er i beta-tilstand og er delvis inkludert i WordPress-kjerne i versjon 4.4. Det er et samfunnsdrevet prosjekt ledet av Ryan McCue og Rachel Baker. Den offisielle arkivsiden av pluginet er plassert på GitHub, og den offisielle dokumentasjonen finnes på nettstedet.
Som nevnt ovenfor er WP REST API for øyeblikket i plugin-tilstand og utvikles aktivt på GitHub. Det har blitt delvis inkludert i WordPress-kjerne i versjon 4.4, og Ryan har beskrevet planen i sin sammenslåing av forslag på WordPress.org.
I henhold til sammenslåingsforslaget vil WP REST API bli innlemmet i WP-kjerne i to trinn som beskrevet nedenfor:
I henhold til forslaget, vil i første fase bare infrastrukturnivåkoden slås sammen i WP-kjernen i utgivelsen 4.4. Denne infrastrukturkoden er selve basen til WP REST API, da den inkluderer JSON serialisering / deserialisering, kobling, innebygd og det viktigste av alt - rutingslaget som driver API-en. Denne koden inkluderer ikke endepunkter og deres kontrollerklasser, men det gir grunnlag for å bygge APIer inne i WordPress.
På tidspunktet for skriving er denne tilstanden fullført og infrastrukturkoden er slått sammen i WordPress-kjerne i versjon 4.4.
Endpoengene for innlegg, sider, brukere og taksonomier etc. vil bli innlemmet i WP-kjernen i utgivelsen 4.5, det vil si en utgivelse senere enn infrastrukturkoden fusjonerer. Endepunktene er det som gjør APIen nyttig for generelle kunder. De inkluderer mye kompleksitet, inkludert kartlegging av eksterne data i JSON-format til native WordPress datatyper, og omvendt. De står for den to tredjedelskoden til API-en selv med ca 5500 linjer.
Strategien her er å bygge utviklerens tillit til API-en ved å først gi infrastrukturkoden i kjernen. Dette ville tillate tema- og pluginutviklere å bygge egendefinerte APIer for å bli inkludert i deres temaer og plugins. Men siden slutpunktene ikke vil bli inkludert på dette stadiet, vil dette begrense bruken av API-en i utgangspunktet.
Gapet mellom de to utgivelsene ville gi WP-kjernekommisjonærlaget nok tid til å se gjennom API-endepunktene.
En annen fordel at WP REST API vil bringe til WordPress-fellesskapet, er bruken av GitHub i versjon som styrer prosjektet. Siden alle bidragene til WordPress er laget gjennom SVN og Trac, er WP REST API-teamet helt sikker på å forbedre bidragsprosessen ved å bygge bro mellom gapet mellom Trac og GitHub.
Etter sammenslåingen av API-en i kjernen, kan vi håpe å se raske utviklinger i andre områder, inkludert OAuth 1.0a-godkjenning.
For å begynne å teste med WP REST API trenger vi en HTTP-klient som vil bli brukt til å sende forespørsler til serveren og vise svaret. Det er egentlig et spørsmål om ditt valg, men jeg bruker Postman for Google Chrome i denne serien. Andre alternativer til Postman er:
Postman tillater oss å lage raske HTTP-forespørsler av forskjellige metoder, se svar fra serveren og testkonfigurasjonen for godkjenning. Alle disse funksjonene kommer svært praktisk når du arbeider med WP REST API.
Den neste tingen vi må ha på vår server er WP-CLI. Med WP-CLI kan vi eksternt administrere vår WordPress-installasjon fra konsollen uten å måtte åpne nettleservinduet. Vi må bruke WP-CLI i neste del av denne serien når du konfigurerer OAuth 1.0a-godkjenning. Du finner installasjonsinstruksjonene på det offisielle nettstedet.
Bortsett fra en HTTP-klient og WP-CLI, trenger vi også demodata for vår WordPress-installasjon. Jeg foreslår at du sjekker ut Tema Enhetstest (XML) eller Demo Data Creator-pluginet som gjør det mulig å opprette flere innlegg, sider og brukere.
Når du skriver denne opplæringen, er den nåværende stabile versjonen 1.2.2 som finnes på det offisielle depotet. I denne serien vil vi jobbe med versjon 2.0 som den har blitt omskrevet fra grunnen og inneholder mange bryteendringer. Du kan hente versjon 2 beta fra den offisielle plugin-siden eller fra GitHub-depotet.
Vær oppmerksom på at det ikke anbefales å installere gjeldende beta på produksjonsmiljøet ditt. Jeg har satt opp et lokalt WordPress-miljø, og jeg anbefaler at du gjør det for utvikling og testing.
For å installere plugin fra GitHub-depotet, åpner du terminalen og drar pluginet etter at du har gått inn i din / Wp-content / plugins / katalogen:
$ git trekke https://github.com/WP-API/WP-API.git
Pluggen lastes ned i / WP-API / katalog.
Du kan aktivere den fra WordPress-administrasjonen for å fortsette å teste med den.
For at WP REST API-plugin skal virke, må du aktivere ganske permalinks med WordPress. Det antas her at du allerede vet å utføre denne grunnleggende handlingen. Hvis du ikke gjør det, har ingen bekymringer som WordPress.org fått deg dekket.
Etter at plugin-modulen er installert, kan vi vurdere tilgjengeligheten av API-en på serveren vår. Vi er ikke begrenset til å bruke APIen bare på nettstedet vårt, faktisk bruker vi det på et hvilket som helst nettsted som har det installert og aktivert. For å se etter API på andre nettsteder, kan vi sende en HEAD-forespørsel til nettstedet som følgende ved hjelp av HTTP-klienten din:
$ HEAD http://someothersite.com/
Dette vil returnere noe som følger i svarhodet:
De link header peker på ruten for WP API som i vårt tilfelle er følgende:
http: // Local / wordpress-api / wp-JSON /
API-en kan også oppdages via JavaScript i nettleseren (eller jQuery) ved å spørre DOM for det aktuelle element som følgende:
(funksjon ($) var $ link = $ ('link [rel = "https://github.com/WP-API/WP-API")'); var api_root = $ link.attr ('href') ;) (jQuery);Herfra kan vi begynne å hente innholdet fra nettstedet gjennom WP REST API. Vær oppmerksom på at kun autentiserte forespørsler kan redigere eller oppdatere innholdet på nettstedet, og jeg lagrer emnet for å konfigurere godkjenning for de neste to delene av denne serien.
I denne introduksjonsdelen av serien lærte vi ganske mye om REST-arkitekturen, WP REST API og HTTP selv. Vi så først på grunnleggende konsepter som REST-arkitekturen er, og hvordan den kan hjelpe utviklere til å skape bedre applikasjoner. Da lærte vi om HTTP, dets verker og svartyper. Vi så også på kort historie om APIer i WordPress og hvordan WP REST API er forskjellig fra forgjengerne.
I den siste delen av denne opplæringen installerte vi pluginet fra GitHub. Etter det ble vi kjent med a HODE forespørsel som kan brukes til å bestemme tilgjengeligheten av API-en på serveren vår og på andre servere.
Etter å ha satt opp det grunnleggende arbeidsmiljøet, er vi klare til å jobbe med funksjonene WP REST API gir. I neste del av serien ser vi på måter å sette opp autentiseringsmetoder som støttes av API. Disse autentiseringsmetodene kreves når du sender forespørsel for å hente, opprette, oppdatere eller slette innhold. Så hold deg innstilt.
