WP REST API Internals och Anpassning

I den föregående delen av serien lärde vi oss att skapa, uppdatera och radera innehåll på distans via WP REST API. Det gör det möjligt för oss att skapa plattformsoberoende program som fungerar sömlöst med ett WordPress-powered back-end, vilket ger en rik erfarenhet till användaren.

I den nuvarande delen av serien ser vi på interneringarna i WP REST API och hur de arbetar tillsammans för att driva API: n. Därefter kommer vi att lära oss att modifiera serverns svar för standardändpunkterna för att inkludera anpassade fält.

För att vara specifik, i den nuvarande artikeln kommer vi att

lära sig om de interna klasserna och metoderna i WP REST API
Ändra serverns svar för standardändpunkter
Lär dig hur man gör anpassade fält redigerbara

Så låt oss börja med att titta på internerna i WP REST API.

Interna klasser och metoder för WP REST API

Klasser i WP REST API kan delas in i följande två kategorier:

Infrastruktur klasser: Det här är de grundläggande klasserna som ansvarar för att hålla ihop API: n. De utför ingen datatransformation.
Slutpunktsklasser: Dessa klasser ansvarar för att utföra CRUD-verksamhet på resurser som inlägg, sidor, användare, kommentarer, etc..

Låt oss ta en titt på de enskilda klasserna i var och en av de två ovanstående kategorierna.

Infrastruktur klasser

De tre infrastrukturklasserna som tillsammans driver REST API är följande:

WP_REST_Server
WP_REST_Request
WP_REST_Response

WP_REST_Server

Detta är kärnklassen i WP REST API som implementerar REST-servern genom att registrera rutter, betjäna förfrågningar och förbereda svar. Den formaterar de data som ska överföras till klienten och i händelse av ett fel förbereder det felet genom att inkludera felkoden och meddelandekroppen. Det kontrollerar också för autentisering.

Vi har jobbat ganska mycket med / Wp-json index-slutpunkt för att kontrollera alla funktioner och stödjade rutter för en webbplats. Metoden get_index (), som ansvarar för att hämta webbplatsindexet finns också i den här klassen.

För att betjäna förfrågningar och förbereda svar, ska WP_REST_Server klassen använder WP_REST_Request och WP_REST_Response klasser respektive.

WP_REST_Request

De WP_REST_Request klassen implementerar begäran objektet för WP REST API. Den innehåller data från förfrågan som rubriker och begäran, och vidarebefordras till återuppringningsfunktionen av WP_REST_Server klass. Det kontrollerar också om parametrarna som skickas längs förfrågan är giltiga och utför datasanisering när det behövs.

WP_REST_Response

De WP_REST_Response klass, som namnet antyder, implementerar svarobjektet. Den innehåller nödvändiga data, såsom svarstatuskod och svarkropp.

Låt oss nu titta på slutpunktsklasserna.

Slutpunktsklasser

Slutpunktsklasserna i WP REST API är ansvariga för att utföra CRUD-operationer. Dessa klasser inkluderar WP_REST_Posts_Controller, WP_REST_Taxonomies_Controller, WP_REST_Users_Controller, etc. Alla dessa slutpunktsklasser omfattar en enda abstrakt klass WP_REST_Controller som ger ett konsekvent mönster för att modifiera data.

De WP_REST_Controller klassen inkluderar metoder som get_item (), create_item (), update_item (), radera sak(), etc., för att utföra CRUD-operationer. Dessa metoder måste överskridas av underklasser genom att implementera sin egen abstraktion för att hämta, skapa, uppdatera och modifiera data.

Du hittar mer om dessa klasser och deras interna metoder i den officiella dokumentationen.

Efter att ha läst om de interna klasserna i WP REST API, kan vi titta på hur vi kan modifiera serverns svar för standardändpunkterna för att inkludera anpassade fält.

Ändra serverresponser

I det föregående avsnittet tittade vi på de interna klasserna och metoderna som API bygger på. Tillsammans kör dessa klasser och metoder API som helhet och ger ett sätt för utvecklare att förlänga API: n för att ta hänsyn till olika scenarier och använda fall.

WP REST API exponerar data på ett förutsägbart sätt. Detta inkluderar olika resurser som inlägg, posta meta, sidor och användare, tillsammans med deras standardegenskaper. Men dessa data kan inte alltid överensstämma med behoven hos varje enskild WordPress-webbplats eller användare. Därför ger WP REST API ett sätt att ändra de data som servern returnerar för var och en av standardrutorna.

De register_rest_field () Metoden ger ett sätt att lägga till eller uppdatera fält i svaret för ett objekt. Att byta fält från ett svar uppmuntras dock aldrig av API: n eftersom det kan introducera kompatibilitetsproblem för klienter som förväntar sig ett vanligt svar från servern. Så om du behöver ändra ett fält, bör du överväga att duplicera fältet med önskat värde.

På samma sätt är borttagning av ett standardfält väldigt avskräckt av anledningen till att en klient kan förvänta sig det. Om du behöver en mindre delmängd av svaret som returneras av servern bör du skapa ytterligare sammanhang utöver standardkontexten som se eller redigera.

Vi kan emellertid säkert lägga till ett fält i svaret som serveren returnerar för ett eller flera objekt. Dessa fält kan innehålla något värde som sträcker sig från post eller användare meta till något annat godtyckligt värde.

I nästa avsnitt arbetar vi med register_rest_field () Metod för att lägga till anpassade fält till svaret som returneras av servern för posta objekt.

Arbeta med `register_rest_field ()` Metod

Som tidigare nämnts, register_rest_field () Metoden kan användas för att lägga till eller uppdatera fält i svaret som returneras av servern. Denna metod accepterar tre argument:

$ objekttyp
$ Attribute
$ args

De $ objekttyp argument kan antingen vara en sträng eller en array som innehåller namnen på alla objekt som vi vill lägga till fältet för. Dessa objekt kan vara posta, termin, kommentar, användare, etc. Om vi behöver lägga till ett anpassat fält till en anpassad posttyp, så $ objekttyp argument skulle vara namnet på posttypen.

De $ Attribute argumentet är namnet på det anpassade fältet. Detta namn visas i serverns svar som en nyckel tillsammans med dess värde.

De $ args array är en associativ array som kan innehålla följande tre nycklar:

$ get_callback
$ update_callback
$ schema

Värdena för de två första tangenterna är namnen på de metoder som används för att få eller uppdatera värdet på det egna fältet. Den sista $ schema nyckeln definierar metoden eller variabeln som används för att definiera schemat för det egna fältet.

Alla ovanstående nycklar är frivilliga, men om de inte läggs till kommer inte kapaciteten att läggas till. Till exempel, om du definierar $ get_callback nyckeln men inte den $ update_callback nyckeln, hämtningsfunktionen läggs till men uppdateringsfunktionen läggs inte till. Om du släpper bort $ get_callback nyckel kommer fältet inte att läggas till svaret alls.

De register_rest_field () Metoden fungerar genom att ändra $ wp_rest_additional_fields variabel. Denna arrayvariabel innehåller registrerade fält efter objekttyper som ska returneras i svaret från servern. När ett fält är registrerat av register_rest_field () metod, det läggs till i $ wp_rest_additional_fields variabel. Ändring av $ wp_rest_additional_fields variabel manuellt är starkt avskräckt.

Lägga till anpassade fält till svaret

Att ha bekantat oss med register_rest_field () metod kan vi nu ändra svaret för posta objekt. Ett typiskt användningsfall här skulle vara tillägget av ett författningsnamnfält, vilket vanligtvis behövs när du listar inlägg på en indexsida. Eftersom standardsvaret inte innehåller detta fält kan vi använda register_rest_field () metod för att inkludera det i svaret.

Vi börjar med att skapa ett enkelt plugin. Så skapa en ny mapp som heter Resten-respons-modifierare i din / Wp-content / plugins katalogen. Skapa en tom index.php fil och klistra in i följande plugin definition:

De register_rest_field () Metoden ska registreras i rest_api_init verkan. Därför skapar vi en funktion som heter bs_add_custom_rest_fields () och binda den till rest_api_init krok:

Observera att de öppna PHP-taggarna krävs inte här, men jag har inkluderat dem så att syntaxen är markerad korrekt.

Inuti bs_add_custom_rest_fields () funktion kan vi använda register_rest_field () metod för att inkludera ett fält för författarnamn:

funktion bs_add_custom_rest_fields () // schema för fältet bs_author_name $ bs_author_name_schema = array ('description' => 'Namn på postförfattaren', 'typ' => 'string', 'context' => array ('view') ); // registrera fältet bs_author_name register_rest_field ('post', 'bs_author_name', array ('get_callback' => 'bs_get_author_name', 'update_callback' => null, 'schema' => $ bs_author_name_schema));

Som nämnts i föregående avsnitt, det första argumentet i register_rest_field () Metoden är namnet på objektet som vi modifierar svaret på. Eftersom vi behöver ändra svaret för posta objekt, vi överensstämmer med det första argumentet.

Det andra argumentet i ovanstående kod är namnet på fältet som kommer att visas i svaret. Det är alltid en bra praxis att prefixa namnet på ett anpassat fält i svaret för att säkerställa maximal framåtkompatibilitet och att den inte överdrivs i framtiden av andra plugins. Därför passerar vi bs_author_name i det andra argumentet som $ Attribute av det anpassade fältet.

Det tredje och sista argumentet i ovanstående kod är en uppsättning för återuppringningsmetoder och schemat. Denna array innehåller namnet på återkallningsmetoderna för hämtning och uppdatering av det anpassade fältet i $ get_callback och $ update_callback nycklarna. Vi passerar bs_get_author_name fungera som återhämtningsåterkallningsmetoden. Vi definierar denna funktion inom kort.

För $ update_callback nyckel passerar vi null eftersom detta är ett skrivskyddat fält och vi behöver inte uppdatera författarnamnet för ett inlägg.

För $ schema nyckel, vi passerar en array som heter $ bs_author_name_schema. Denna array rymmer olika egenskaper för fältet som datatyp, sammanhanget och beskrivningen.

Det enda vi behöver definiera nu är bs_get_author_name () funktion som kommer att fungera som $ get_callback metod för vårt anpassade fält. Nedan är koden för denna funktion:

/ ** * Återuppringning för att hämta författarnamn * @param array $ object Det aktuella postobjektet * @paramsträngen $ field_name Fältets namn * @param WP_REST_request $ request Den nuvarande förfrågan * @return-strängen Namn på författaren * / funktion bs_get_author_name ($ objekt, $ field_name, $ request) return get_the_author_meta ('display_name', $ object ['author']);

De $ get_callback Metoden får tre argument för följande:

$ object: Det aktuella objektet. I vårt fall är det nuvarande inlägget. $ FIELD_NAME: Namnet på det anpassade fältet läggs till. $ begäran: Förfrågan objektet.

Vi använder $ författare egenskapen hos $ object argument som innehar författarens id. Och genom att använda get_the_author_meta () funktion, hämtar vi och returnerar visningsnamnet för författaren till det aktuella inlägget.

Nu när fältet är registrerat kan vi skicka en SKAFFA SIG begäran till / Wp / v2 / inlägg rutt för att se om det fungerar korrekt:

Här är svaret i Postman:

Det här nya registrerade fältet kommer också att visas i serverns svar, tillsammans med dess schema, när vi skickar en ALTERNATIV begäran till / Wp / v2 / inlägg rutt: Därför har ett anpassat fält för författarens namnegenskap registrerats. Men det här fältet är skrivskyddat eftersom vi inte kan uppdatera det genom att skicka ett POSTA begäran. I det följande avsnittet registrerar vi ett redigerbart fält för räkningar med postvisningar. Registrera ett redigerbart fält Vi kommer nu att registrera ett anpassat fält för räkenskaperna för antal vyer. Vi kommer bara att ta itu med den faktiska registreringen av fältet med WP REST API, vilket innebär att implementeringen för att öka räkneantalet lämnas ut. Nedan är koden för bs_post_views anpassad fältregistrering tillsammans med dess schema: // schema för bs_post_views-fältet $ bs_post_views_schema = array ('description' => 'Visa antal gånger', 'typ' => 'heltal', 'context' => array ('view', 'edit')); // registrera bs_post_views fältregister_rest_field ('post', 'bs_post_views', array ('get_callback' => 'bs_get_post_views', 'update_callback' => 'bs_update_post_views', 'schema' => $ bs_post_views_schema)); Koden liknar den som vi skrev i det föregående avsnittet, förutom att det nu innehåller en återkallningsmetod bs_update_post_views för $ update_callback nyckel. Den här funktionen är ansvarig för att uppdatera värdet på fältet. De $ sammanhang egendom i $ bs_post_views_schema schema array innehåller två värden för se och redigera. Inkludering av redigeringsvärde i $ sammanhang argumentet säkerställer att bs_post_views Fältet returneras i serverns svar efter det att det har uppdaterats. Hämta och uppdatera återkallningsmetoder är som följer: / ** * Återuppringning för att hämta antalet postvyer * @param array $ object Det aktuella postobjektet * @param-strängen $ field_name Fältnamnet * @param WP_REST_request $ request Den nuvarande förfrågan * @returns heltal Postvisningsräkning * / funktion bs_get_post_views ($ object, $ field_name, $ request) return (int) get_post_meta ($ object ['id'], $ field_name, true); / ** * Återuppringning för uppdatering av vyer för postvyer * @param blandat $ värde Postvalsräkning * @paramobjekt $ objekt Objektet från svaret * @paramsträngen $ field_name Namn på det aktuella fältet * @return bool | int * / funktion bs_update_post_views ($ värde, $ objekt, $ field_name) om (! $ värde ||! is_numeric ($ value)) return; returnera update_post_meta ($ object-> ID, $ field_name, (int) $ value); Koden är ganska enkel eftersom den använder get_post_meta () och update_post_meta () metoder för att hämta respektive uppdatera värdena. De bs_get_post_views () Metoden först hämtar metavärdet för bs_post_views meta-tangent och kastar den in i ett heltal innan du returnerar det. Återuppringningsmetoden passerade in $ update_callback får tre argument för följande: $ värde: Det nya värdet för fältet. $ object: Aktuellt objekt från svaret. $ FIELD_NAME: Fältets namn uppdateras. I bs_update_post_views () metod, vi kontrollerar först om värdet som skickas inte är tomt och är ett numeriskt värde. Om inte, återvänder vi utan att göra någonting. Om värdet är numeriskt, skickar vi det till update_post_meta () funktion som sparar den till databasen efter typ gjutning den till ett giltigt heltal. Efter att ha registrerat fältet framgångsrikt, låt oss testa det genom att skicka ett SKAFFA SIG begäran: $ GET / wp / v2 / inlägg Nedan visas ett provsvar för ovanstående förfrågan: Som vi kan se i bilden ovan, är nuvärdet av bs_post_views Fältet är 0 för ett visst inlägg. Detta beror på att get_post_meta () Metoden returnerar en tom sträng eftersom den inte kunde hitta ett metavärde för bs_post_views meta-tangent och typgjutning av en tom sträng i ett heltal i PHP resulterar i 0. Vi kan uppdatera bs_post_views fält genom att skicka en POSTA begäran till / Wp / v2 / inlägg / slutpunkt. JSON-kroppen för begäran är följande: "bs_post_views": 4050 Om begäran är framgångsrik returnerar servern a 200 - OK statuskod tillsammans med det uppdaterade postobjektet som också innehåller bs_post_views fält: De bs_post_views Anpassat fält är nu uppdaterat. Observera att vi skickade ett JSON-organ längs begäran om att uppdatera fältet. JSON-kroppen inkluderade fältnamnet-bs_post_views-med ett heltal av 4050. Om vi försöker skicka ett icke-numeriskt värde, säg ”abc1234”, Fältet uppdateras inte eftersom vi har ett villkor för att kontrollera ett numeriskt värde i bs_update_post_views () återuppringningsmetod. Nedan finns den fullständiga källkoden för plugin: 'Namn på författaren', 'typ' => 'string', 'context' => array ('view')); // registrera fältet bs_author_name register_rest_field ('post', 'bs_author_name', array ('get_callback' => 'bs_get_author_name', 'update_callback' => null, 'schema' => $ bs_author_name_schema)); // schema för bs_post_views-fältet $ bs_post_views_schema = array ('description' => 'Visa antal gånger', 'typ' => 'heltal', 'context' => array ('view', 'edit')); // registrera bs_post_views fältregister_rest_field ('post', 'bs_post_views', array ('get_callback' => 'bs_get_post_views', 'update_callback' => 'bs_update_post_views', 'schema' => $ bs_post_views_schema)); / ** * Återuppringning för att hämta författarnamn * @param array $ object Det aktuella postobjektet * @paramsträngen $ field_name Fältets namn * @param WP_REST_request $ request Den nuvarande förfrågan * @returnsträngen Författarens namn * / funktion bs_get_author_name ($ objekt, $ field_name, $ request) return get_the_author_meta ('display_name', $ object ['author']); / ** * Återuppringning för att hämta antalet postvyer * @param array $ object Det aktuella postobjektet * @param-strängen $ field_name Fältets namn * @param WP_REST_request $ request Den nuvarande förfrågan * @returns heltal Postvärden räknas * / funktion bs_get_post_views ($ object, $ field_name, $ request) return (int) get_post_meta ($ object ['id'], $ field_name, true); / ** * Återuppringning för uppdatering av vyer för postvyer * @param blandat $ värde Postvalsräkning * @paramobjekt $ objekt Objektet från svaret * @paramsträngen $ field_name Namn på det aktuella fältet * @return bool | int * / funktion bs_update_post_views ($ värde, $ objekt, $ field_name) om (! $ värde ||! is_numeric ($ value)) return; returnera update_post_meta ($ object-> ID, $ field_name, (int) $ value); Det här är allt för att modifiera serverns svar för standard API-slutpunkter. Vi har knappt repat ytan för att ändra REST API eftersom det ger mycket mer flexibilitet än att bara modifiera serverns svar. Detta inkluderar att lägga till stöd för den anpassade innehållstypen via anpassade kontroller och namnområden och registrera anpassade rutter för att exponera och ändra data. Vi kommer att försöka täcka dessa avancerade ämnen i framtida artiklar. Bara början… Här avslutar vi vår resa för att introducera oss till WP REST API. I denna serie har vi täckt ganska grundläggande begrepp som autentiseringsmetoder och hämtning, skapande och uppdatering av data. I den här sista delen av serien tittade vi kort på de interna klasserna i WP REST API och fick sedan lära sig att modifiera serverns svar för standardändpunkterna. Det var aldrig syftet med denna serie att täcka varje aspekt av WP REST API-faktum kan det aldrig uppnås i en enda serie. Men snarare var syftet med serien att få dig igång med det här fantastiska tillägget och uppmuntra dig att leka och experimentera på egen hand. Jag hoppas att du har funnit att denna serie uppfyller sitt yttersta mål. Koda