Share
I de tidigare delarna av serien har vi tittat på vad WP REST API är och hur det kan hjälpa oss att bygga bättre applikationer med hjälp av WordPress back-end.
Sedan tittade vi på två sätt att konfigurera autentisering på servern för att generera autentiserade förfrågningar. Den första är den grundläggande autentiseringsmetoden, som är användbar i utvecklingsmiljöer och möjliggör snabb prototyper, eftersom det inte kräver mycket tid att installera. Den andra metoden för autentisering är OAuth 1.0a, vilket rekommenderas för produktionsmiljöer eftersom det är mycket säkrare än den grundläggande autentiseringsmetoden.
Nu när vi har lärt oss hur du ställer in autentisering är vi redo att generera autentiserade förfrågningar för att släppa ut hela kraften i WP REST API. Vi använder grundläggande autentisering genom denna serie på grund av användarvänlighet, men det rekommenderas att du använder OAuth 1.0a-autentisering, enligt OAuth 1.0a-plugin, för dina produktionsservrar.
I den nuvarande delen av serien kommer vi att få vår allra första praktiska erfarenhet med pluginprogrammet WP REST API. Vi ska:
Accentsconagua
SKAFFA SIG begäranALTERNATIV begära självdokument API: nSå låt oss börja med att analysera strukturen av en enkel SKAFFA SIG begäran.
SKAFFA SIG BegäranInnan vi gräver i detaljer om att hämta data med WP REST API måste vi bekanta oss med syntaxen för en begäran som skickas till servern. Detta kommer att lägga en solid grund för våra framtida interaktioner med WP REST API.
Tänk på följande förfrågan skickad till servern:
$ GET http: // localserver / wp-json / wp / v2 / inlägg
Den typ av begäran som vi skickar är SKAFFA SIG-ett av sex HTTP-verb som vi tittade på i den första delen av denna serie. en SKAFFA SIG begäran används för att hämta data från servern. När den körs på servern hämtar ovanstående förfrågan en samling av alla postobjekt i form av JSON-data.
Med tanke på begäran URI kan vi bryta den in i följande delar:
http: // localserver /: URL: en för min lokala utvecklingsserver. Det kan vara vilken URL som helst beroende på var din WordPress-installation finns./ Wp-json: Det är slutpunkts prefixet för WP REST API./ wp: Namnutrymmet för WP REST API-plugin./ v2: Det är versionen av pluginprogrammet för WP REST API./ inlägg: Det är den resurs som vi vill hämta från servern.Namnutrymmet förhindrar det överordnade som kan uppstå vid körning av flera plugins med var och en som tillhandahåller sitt eget abstraktionslager för RESTful API. Därför arbetar varje abstraktion i sin egen gräns utan att påverka de metoder och egenskaper som hör till någon annan abstraktion.
Namnrymden och versionen var inte närvarande i den äldre version 1.2 av plugin. Så i äldre versionen skulle ovannämnda förfrågan vara så här:
$ GET http: // localserver / wp-json / inlägg
Men vi kommer inte prata om bakåtkompatibilitet här. Om du vill lära dig om alla förändringar som uppstod mellan version 1.x och 2.x kan du hitta dem på den officiella sidan.
Förutom att hämta en samling resurser (inlägg) med ovanstående URI kan vi också hämta en specifik resurs genom att nämna sitt ID:
$ GET / wp / v2 / inlägg / 100
Ovanstående förfrågan kommer att returnera ett postobjekt eftersom det ser ner för en postresurs som har ett ID på 100.
Andra gånger måste vi också söka efter inlägg som uppfyller vissa specifika kriterier. För det ändamålet ger WP REST API ett sätt att använda filtrera[] syntax:
$ GET / wp / v2 / inlägg? Filter [cat] = 1
Genom att skicka ovanstående förfrågan kan vi hämta alla inlägg som tillhör en kategori ID 1. Filtersyntaxen kan vara särskilt användbar när du frågar inlägg eller navigerar mellan olika resurser, t.ex. inlägg och kategorier, med hjälp av sina relationer.
Slutligen, när man hanterar argument som tar matriser som input i filtrera[] syntax kan vi lägga till en tom uppsättning kvadratkonsoler för att uttrycka arrays som så:
$ GET / wp / v2 / inlägg? Filter [category__and] [] = 1 & filter [category__and] [] = 2
Ovanstående syntax motsvarar följande WP_Query ():
array (1, 2)));
Därför ovanstående SKAFFA SIG begäran kommer hämta en lista över inlägg som hör till båda kategorierna med ett ID på 1 och 2. Samma syntax kan också användas för arrayargument som har mer än två element. Observera att användningen av category__and parametern kräver användarautentisering med edit_posts privilegier.
Vi kommer att undersöka filtrera[] syntax i mer detalj i ett senare avsnitt.
Nu när vi har lärt oss att formatera en SKAFFA SIG begära och ge sina parametrar, är det dags att ta en titt på ALTERNATIV begäran. En ALTERNATIV förfrågan gör det enkelt att navigera genom API: n och fungerar faktiskt som ett självdokumentation för att göra API: n mer tillgängligt genom att dokumentera alla tillgängliga HTTP-metoder på en slutpunkt, och i sin tur de argument de stöder.
ALTERNATIV BegäranSom tidigare nämnts ALTERNATIV begäran kan vara till stor hjälp när du utforskar API: n. Det nämner alla slutpunkter som hör till en viss rutt och ger en lista med parametrar dessa ändpunkter stödjer CRUD-operationer.
Låt oss skicka en ALTERNATIV begäran till / Wp / v2 / inlägg rutt för att kontrollera vilka ändpunkter den stöder och vilka parametrar vi kan passera längs SKAFFA SIG begära att fråga data:
$ curl -X OPTIONS wp / v2 / inlägg
Jag har använt cURL för att skicka ovanstående förfrågan, men du kan använda valfritt verktyg, inklusive Postman. Var noga med att inkludera hela sökvägen till ovanstående rutt, inklusive sökvägen till din server.
"namespace": "wp / v2", "metoder": [...], "slutpunkter": [...], "schema": ..., "_links": ...
Ovanstående ALTERNATIV begäran till / Wp / v2 / inlägg Rutt returnerar data i JSON-formatet som innehåller fem egenskaper:
namespacemetoderendpointsschema_links"namespace": "wp / v2", ...
De namespace egendom identifierar namnrymden för det aktuella plugin. I vårt fall är det wp / v2, betecknar version 2 i WP REST API. Vi har redan tittat på namnrymden och det syfte som det tjänar i föregående avsnitt.
... "metoder": ["GET", "POST"], ...
De metoder Egenskapen innehåller en uppsättning av alla metoder som stöds av den aktuella rutten. Genom att titta på svaret gav den ovannämnda begäran tillbaka det klart att / Wp / v2 / inlägg Rutt stöder två metoder, nämligen SKAFFA SIG och POSTA. Det betyder att vi kan använda / Wp / v2 / inlägg rutt för att hämta inlägg, samt skapa ett nytt inlägg. Vi kommer att ta itu med POSTA metod i nästa del av denna serie, så låt oss bara fokusera på SKAFFA SIG metod för tillfället.
Nästa fastighet-endpoints-innehåller en uppsättning av de stödda ändpunkterna för den aktuella rutten. Den här egenskapen är direkt kopplad till den tidigare nämnda metoder egenskap eftersom den listar slutpunkter för de stödda metoderna.
... "ändpunkter": ["metoder": ["GET"], "args": ..., "metoder": ["POST"], "args": ..., ...
De endpoints Egenskapen innehåller objektvärden som i sin tur innehåller två egenskaper, nämligen metoder och args. De metoder Egenskapen innehåller en uppsättning HTTP-metoder och nästa args Egenskapen innehåller alla argument som stöds för dessa metoder. Det här är de argument som vi skickar längs begäran i form av URI-parametrar.
Titta på argumenten som stöds av SKAFFA SIG metod, vi stöter på nio argument som inkluderar sammanhang, sida, per sida, etc. Dessa argumentobjekt innehåller två egenskaper, nödvändig och standard. De nödvändig Egenskapen indikerar om argumentet är obligatoriskt och standard egenskapen representerar argumentets standardvärde.
"metoder": ["GET"], "args": "context": "krävs": false, "default": "view", "sida": "krävs": false, "default" 1, "per_sida": "krävs": falskt, "standard": 10, "filter": "krävs": false
De schema egendom i det returnerade svaret dokumenterar alla egenskaper för den aktuella resursen. Schemat definierar en struktur för data i JSON-formatet. Schemaformatet som används i WP REST API är baserat på utkast 4 i JSON schema specifikationerna.
Den sista _links Egenskapen innehåller en rad objekt som innehåller länkarna till associerade resurser. Nyckeln i objektet anger relationstypen (t.ex.. författare, samling, själv, kommentarer, etc.), med sitt värde som länken till den därmed sammanhängande resursen. Denna länkstandard är baserad på HAL (Hypertext Application Language). Du kan hitta mer om HAL genom att läsa specifikationerna som skapats av Mike Kelley.
På ett liknande sätt kan vi skicka en ALTERNATIV Be om andra vägar, inklusive användarnas, kommentarer, media, sidor etc. för att kontrollera deras stödda metoder och argument. ALTERNATIV Förfrågningar är din bästa vän när du arbetar med WP REST API.
WP REST API ger ännu ett sätt att bedöma API-tillgängligheten genom att skicka en SKAFFA SIG begäran till / Wp-json indexväg. Här listas alla rutter och deras slutpunkter tillsammans med deras stödda metoder och argument.
$ curl -X GET http: // wordpress-server / wp-json
Ovanstående förfrågan kommer att returnera ett svarobjekt som innehåller en ruttegenskap enligt följande:
Denna funktion är oerhört kraftfull eftersom den listar alla rutter och deras stödda metoder och argument, vilket eliminerar behovet av att alla dessa dokumenteras externt. Vi kommer att referera till detta svarobjekt när vi utför CRUD-operationer på olika resurser.
Vi har tittat på våra alternativ för att utforska API: n, nu börjar vi arbeta med WP REST API för att hämta data från servern.
Nu har vi bekantat oss med ALTERNATIV begäran, vilket är ett självdokumentande sätt att bedöma API-tillgängligheten. Vi tittade också på hur det visar stödda metoder och argument för en given rutt. Med hjälp av denna kunskap är vi nu redo att hämta olika resurser från servern med hjälp av WP REST API.
Resursen vi ska börja med är inlägg resurs, eftersom det är huvudbyggnaden av WordPress. Vi kommer att hantera hämtning av inlägg med olika filter. Genom att använda denna kunskap kommer du att kunna fråga inlägg via WP REST API precis som du gör med WP_Query () klassen.
Under hela serien har vi arbetat med inlägg resurs för att visa exemplarförfrågningar och deras svar, och vi vet redan hur man hämtar postkollektion och en enskild post med sitt ID. Så vi kommer inte att täcka det igen. I stället kommer vi att titta på några mer avancerade sätt att hämta inlägg med parametrar på toppnivå och filtrera[] syntax.
WP REST API visar några av de vanligaste frågvariablerna för inlägg direkt på SKAFFA SIG slutpunkt. Dessa parametrar är:
sammanhang: Omfanget av begäran. Möjliga värden kan vara se, bädda in eller redigera.sida: Den aktuella sidan i postsamlingen.per sida: Totalt antal inlägg per sida.Sök: Sökfrågan. Begränsa resultat till matchande sträng.författare: Författarens ID. Används för att begränsa resultat som tillhör en viss författare.utesluta: En rad postposter som ska uteslutas från sökresultat.inkludera: Begränsa resultaten till post-ID-er som anges i denna array.offset: Offset sökresultaten med angivet nummer.ordning: Kollektionsordningen. Kan antingen vara asc eller desc.sortera efter: Sortering av attribut hos samlingen. Möjliga värden kan vara id, titel eller snigel.snigel: Begränsa resultaten till ett inlägg med en viss slug.status: Används för att begränsa samlingen av inlägg som har en viss status.De sammanhang Parametern används för att hämta inlägg beroende på omfattningen vi arbetar med. Om vi bara listar inlägg på någon indexsida, så är vi bra att gå med se sammanhang. Men om vi hämtar inlägg för att redigera dem måste vi använda redigera sammanhang:
$ GET / wp / v2 / inlägg? Context = edit
De redigera context parameter introducerar ytterligare rå fält i fält som titel, innehåll, utdrag, etc. Värdet av detta rå Fältet kan echoed ut i redigeraren för att redigera innehållet.
Använda redigera sammanhang kräver att du autentiseras som användare med edit_posts privilegier.
Använder sig av bädda in som värdet av sammanhang parameter hämtar samlingen av inlägg med en minimal delmängd av deras egenskaper.
De andra parametrarna ovan är ganska självförklarande, och du kan leka med dem i din HTTP-klient.
Dessa var de grundläggande parametrarna som låter dig fråga inlägg baserat på vissa kriterier. För att begränsa våra frågningsfunktioner tillhandahåller WP REST API filtrera[] syntax som stöder en delmängd av WP_Query () args.
filtrera[] SyntaxFörutom att hämta en samling inlägg med några grundläggande översta parametrar, avslöjar WP REST API några av de WP_Query () variabler som använder filtrera[] syntax. Genom att använda denna syntax kan vi fråga inlägg på samma sätt som vi gör när vi arbetar med WP_Query () klass.
Paginationsparametrar är de viktigaste av alla filtren, eftersom de används i stor utsträckning på postlistan. Paginationsparametrarna tillåter oss att visa ett visst antal inlägg per sida och navigera till ett visst antal sidor som innehåller inlägg.
Som standard a SKAFFA SIG Förfrågan hämtar en samling på 10 inlägg per sida. Låt oss se hur vi kan skicka in en SKAFFA SIG Begär att hämta endast fem inlägg per sida:
$ GET / wp / v2 / inlägg? Filter [posts_per_page] = 5
Ovanstående förfrågan använder posts_per_page variabel som du kanske känner till om du har arbetat med WP_Query ().
De paged Parametern används tillsammans med posts_per_page parameter, och det används för att navigera till ett visst antal sidor. Efter att ha hämtat fem inlägg per sida, skulle vi göra följande förfrågan att navigera till den andra sidan:
$ GET / wp / v2 / inlägg? Filter [posts_per_page] = 5 & filter [paged] = 2
De posts_per_page och paged Filter kan vara mycket praktiskt när du arbetar för att bygga paginering på listningssidor med hjälp av WP REST API. Dessa två parametrar motsvarar per sida och sida parametrar på hög nivå. Följaktligen gör följande förfrågan samma arbete som ovanstående:
$ GET / wp / v2 / inlägg? Per_page = 5 & sida = 2
Förutom att samlingen av inlägg returnerar ovanstående begäran returnerar servern också ett antal rubriker med ett svar som innehåller användbar information, inklusive det totala antalet inlägg och antalet sidor. Dessa värden finns i X-WP-TotalPages och X-WP-Total svarhuvud.
De X-WP-TotalPages och X-WP-Total svarhuvuden är extremt användbara när du skapar pagination med WP REST API, eftersom de anger totalt antal sidor och totalt antal inlägg.
Förutom pagineringsfilter, den andra viktigaste användningen av filtrera[] syntaxen är att kunna fråga inlägg efter deras datum. För detta ändamål, filtrera[] syntaxen stöder åtta parametrar, samma som i WP_Query () klass:
år: Det fyrsiffriga året (t ex 2015 eller 2016)monthnum: Månadens nummer från 1 till 12m: Sexsiffrig årsmånad (t ex 201601)w: Årets vecka från 0 till 53dag: Månadens dag från 1 till 31timme: Dygnet på dagen från 0 till 23minut: Timmars minut från 0 till 60andra: Den andra i minuten från 0 till 60Så om vi letar efter de inlägg som publicerades på datumet 2015-10-15 (åååå / mm / dd) kan detta uppnås med följande fråga:
$ GET / wp / v2 / inlägg? Filter [år] = 2015 och filter [månad] = 10 och filter [dag] = 15
En liknande fråga kan förberedas med hjälp av ovanstående parametrar om vi behöver begränsa vår sökning till exakt timme och minut.
Vi har redan sett i en tidigare del av denna handledning hur vi kunde hämta inlägg som tillhör en viss kategori eller flera kategorier med hjälp av filtrera [cat] och filtrera [category__and] parametrar. Nu ska vi använda filtrera [category__in] parameter för att visa inlägg som tillhör kategorier med ett ID på 5 och 6:
$ GET / wp / v2 / inlägg? Filter [category__in] [] = 5 & filter [category__in] [] = 6
Ovanstående förfrågan kommer att hämta en lista över alla inlägg som tillhör kategorier med ID 5 och 6.
Den motsatta effekten kan uppnås genom att använda filtrera [category__not_in] parameter på följande sätt:
$ GET / wp / v2 / inlägg? Filter [category__not_in] [] = 5 & filter [category__not_in] [] = 6
Detta hämtar en lista med inlägg medan alla poster som tillhör kategorier med ett ID på antingen 5 eller 6 exkluderas.
Mer kan skrivas på med hjälp av filtrera[] syntax, men jag kommer inte att täcka allt det här. Du kan hitta en lista över alla fråga variabler som stöds av filtrera[] syntax i den officiella dokumentationen av version 1 i plugin. En stor del av denna information gäller fortfarande med version 2 i WP REST API, men saknas fortfarande i vissa områden. Vid tidpunkten för skrivandet av denna handledning anges inte den officiella dokumentationen av version 2 något om filtrera[] syntax och frågan vars den stöder, men vi kan hoppas att se förbättringar i den officiella dokumentationen inom en snar framtid eftersom det finns ett antal personer (inklusive mig själv) som bidrar till pluginutvecklingen och dokumentationen.
Nu när vi har tittat på olika alternativ när du frågar inlägg med hjälp av WP REST API, är vi redo att vidareutveckla vår resa och titta på några andra resurser som stöds av WP REST API.
Postrevisioner ger ett sätt att visa och återställa ändringar som gjorts till ett inlägg. WP REST API ger dig möjlighet att visa alla ändringar av ett inlägg genom att fråga / tjänster / slutpunkt. Därför för en viss post med ett ID på 10 kan alla revisioner hämtas genom att skicka följande förfrågan:
$ GET / wp / v2 / inlägg / 10 / revisioner
Ovanstående förfrågan kommer att returnera en array som innehåller revisionsobjekt. Ändringsobjektet innehåller en delmängd av egenskaper som finns i postobjektet. Nedan visas ett exempel på revisionsobjekt i Postman:
En specifik revision kan hämtas med tanke på att vi känner till dess id. Så en revision med ett ID på 2 med inlägg med ett ID på 10 kan hämtas av följande objekt:
$ GET / wp / v2 / inlägg / 10 / revisioner / 2
Ovanstående förfrågan kommer att returnera ett enda revisionsobjekt.
Andra än postrevisioner kan kategorier för ett specifikt inlägg hämtas med följande förfrågan:
$ GET / wp / v2 / kategorier? Post =
Och för taggarna använder vi följande förfrågan:
$ GET / wp / v2 / tags? Post =
Med
Om vi behöver hämta postmeta för post som har ett ID på 10 skickar vi följande förfrågan som en autentiserad användare:
$ GET / wp / v2 / inlägg / 10 / meta
Detta kommer att returnera en rad metaobjekt.
Observera att för att arbeta med post och sida meta i WP REST API måste du ha kompaniet plugin installerat tillgängligt på GitHub av WP REST API-teamet.
Nu har vi fått en ganska solid grund för att arbeta med WP REST API för att hämta data. Vi har redan tittat på alternativförfrågan och hur det hjälper oss att utforska API: n utan behov av extern dokumentation.
Du kan alltid skicka en ALTERNATIV begära en viss resurs och kontrollera vilka slutpunkter och parametrar den stöder. Om du behöver lista alla de rutter som WP REST API tillhandahåller kan du skicka en SKAFFA SIG begäran till indexändpunkt på / Wp-json som vi lärde oss göra i början av denna handledning.
Med tanke på denna fördel med självdokumentation tror jag inte att vi ytterligare behöver utforska varje enskild resurs i denna handledning, eftersom ni nu kan göra det själv.
I den här långa handledningen lärde vi oss att utforska API: n med hjälp av OPTIONS-förfrågan och hämta data från servern med hjälp av WP REST API. Vi tittade bara på en handfull resurser, inklusive inlägg, postrevision och posta meta, eftersom vi inte kunde täcka alla stödda resurser i bara en handledning. Men du borde nu kunna utforska API på egen hand med hjälp av de tekniker som vi lärde oss i den här handledningen.
WordPress har en oerhört aktiv ekonomi. Det finns teman, plugins, bibliotek och många andra produkter som hjälper dig att bygga upp din webbplats och ditt projekt. Plattformens open source-natur gör det också till ett bra alternativ, från vilket du kan förbättra dina programmeringsförmåga. Oavsett fall kan du se vad allt finns tillgängligt på Envato Marketplace.
I nästa del av denna serie kommer vi att lära oss att utföra de andra tre operationerna av CRUD, dvs skapa, uppdatera och ta bort resurser. Så håll dig uppdaterad ...
