WP REST API interne en maatwerk

In het vorige deel van de serie leerden we over het maken, bijwerken en verwijderen van content op afstand via de WP REST API. Hiermee kunnen we platformonafhankelijke applicaties maken die naadloos aansluiten op een door WordPress aangedreven back-end en de gebruiker een rijke ervaring bieden..

In het huidige deel van de serie zullen we de interne onderdelen van de WP REST API bekijken en bekijken hoe deze samenwerken om de API van stroom te voorzien. Hierna zullen we leren om serverreacties voor de standaard eindpunten te wijzigen om aangepaste velden op te nemen.

Om specifiek te zijn, in het huidige artikel zullen we:

leren over de interne klassen en methoden van de WP REST API
wijzig de serverrespons voor standaard eindpunten
leer hoe u aangepaste velden bewerkbaar maakt

Laten we daarom beginnen met een kijkje te nemen naar de internals van de WP REST API.

Interne klassen en methoden van de WP REST API

Klassen in de WP REST API kunnen worden onderverdeeld in de volgende twee categorieën:

Infrastructuur klassen: Dit zijn de fundamentele klassen die verantwoordelijk zijn voor het bij elkaar houden van de API. Ze voeren geen gegevenstransformatie uit.
Eindpuntklassen: Deze klassen zijn verantwoordelijk voor het uitvoeren van CRUD-bewerkingen op bronnen zoals berichten, pagina's, gebruikers, opmerkingen, enzovoort.

Laten we de afzonderlijke klassen van elk van de twee bovengenoemde categorieën bekijken.

Infrastructuurklassen

De drie infrastructuurklassen die samen de REST API van stroom voorzien zijn:

WP_REST_Server
WP_REST_Request
WP_REST_Response

WP_REST_Server

Dit is de kernklasse van de WP REST API die de REST-server implementeert door routes te registreren, verzoeken te leveren en antwoorden voor te bereiden. Het formatteert de gegevens die moeten worden doorgegeven aan de client en in geval van een fout bereidt het de fout voor door de foutcode en de berichttekst op te nemen. Het controleert ook op authenticatie.

We hebben veel met de. Gewerkt / Wp-json index eindpunt voor het controleren van alle mogelijkheden en ondersteunde routes voor een site. De methode get_index (), die verantwoordelijk is voor het ophalen van de site-index, bevindt zich ook in deze klasse.

Voor serververzoeken en het voorbereiden van reacties, de WP_REST_Server class gebruikt de WP_REST_Request en WP_REST_Response klassen respectievelijk.

WP_REST_Request

De WP_REST_Request class implementeert het aanvraagobject voor de WP REST API. Het bevat gegevens van het verzoek, zoals headers en request body, en wordt doorgegeven aan de callback-functie WP_REST_Server klasse. Het controleert ook of de parameters die worden doorgegeven aan de aanvraag geldig zijn en voert indien nodig gegevensreiniging uit.

WP_REST_Response

De WP_REST_Response klasse, zoals de naam aangeeft, implementeert het antwoordobject. Het bevat de benodigde gegevens, zoals de antwoordstatuscode en de antwoordinstantie.

Laten we nu eens kijken naar de eindpuntklassen.

Eindpuntklassen

De eindpuntklassen in de WP REST API zijn verantwoordelijk voor het uitvoeren van CRUD-bewerkingen. Deze klassen omvatten WP_REST_Posts_Controller, WP_REST_Taxonomies_Controller, WP_REST_Users_Controller, enz. Al deze eindpuntklassen breiden een enkele abstracte klasse uit WP_REST_Controller die een consistent patroon biedt voor het wijzigen van gegevens.

De WP_REST_Controller klasse omvat methoden zoals get_item (), create_item (), update_item (), Verwijder item(), enz., voor het uitvoeren van CRUD-bewerkingen. Deze methoden moeten worden overschreven door subklassen door hun eigen abstractie te implementeren voor het ophalen, maken, bijwerken en wijzigen van gegevens.

U kunt meer over deze klassen en hun interne methoden vinden in de officiële documentatie.

Hebben we geleerd over de interne klassen van de WP REST API, laten we eens kijken hoe we serverreacties kunnen aanpassen voor standaard eindpunten om aangepaste velden te bevatten.

Serverreacties aanpassen

In de vorige sectie hebben we gekeken naar de interne klassen en methoden waarop de API is gebaseerd. Samen stimuleren deze klassen en methoden de API als geheel en bieden ontwikkelaars een manier om de API uit te breiden naar verschillende scenario's en use cases.

De WP REST API legt data op een voorspelbare manier bloot. Dit omvat verschillende bronnen, zoals berichten, berichten meta, pagina's en gebruikers, samen met hun standaard eigenschappen. Maar deze gegevens kunnen niet altijd voldoen aan de behoeften van elke afzonderlijke WordPress-site of -gebruiker. Daarom biedt de API WP REST een manier om de gegevens te wijzigen die de server retourneert voor elk van de standaardroutes.

De register_rest_field () methode biedt een manier om velden in het antwoord voor een object toe te voegen of bij te werken. Het wijzigen van een veld uit een antwoord wordt echter nooit aangemoedigd door de API, omdat hierdoor compatibiliteitsproblemen kunnen ontstaan voor clients die een standaardantwoord van de server verwachten. Dus als u een veld moet wijzigen, kunt u overwegen het veld met de gewenste waarde te dupliceren.

Evenzo wordt het verwijderen van een standaardveld ten zeerste afgeraden vanwege de reden waarom een klant dit misschien verwacht. Als u een kleinere subset van het antwoord van de server nodig hebt, moet u extra contexten maken naast de standaardcontexten zoals uitzicht of Bewerk.

We kunnen echter veilig een veld toevoegen aan het antwoord dat door de server wordt geretourneerd voor een of meerdere objecten. Deze velden kunnen elke waarde bevatten, variërend van post- of gebruikers-meta tot elke andere willekeurige waarde.

In het volgende gedeelte zullen we werken met de register_rest_field () methode om aangepaste velden toe te voegen aan het antwoord geretourneerd door de server voor de post voorwerp.

Werken met de `register_rest_field ()` Methode

Zoals eerder vermeld, de register_rest_field () methode kan worden gebruikt om velden toe te voegen of bij te werken in het antwoord dat door de server wordt geretourneerd. Deze methode accepteert drie argumenten:

$ object_type
$ attribuut
$ args

De $ object_type argument kan een tekenreeks of een array zijn met de namen van alle objecten waarvoor we het veld willen toevoegen. Deze objecten kunnen zijn post, termijn, commentaar, gebruiker, enz. Als we een aangepast veld aan een aangepast berichttype moeten toevoegen, dan is het $ object_type argument zou de naam van het berichttype zijn.

De $ attribuut argument is de naam van het aangepaste veld. Deze naam verschijnt in de serverrespons als een sleutel, samen met de waarde ervan.

De $ args array is een associatieve array die de volgende drie sleutels kan bevatten:

$ get_callback
$ update_callback
$ schema

De waarden van de eerste twee sleutels zijn de namen van de methoden die worden gebruikt om de waarde van het aangepaste veld op te halen of bij te werken. De laatste $ schema key definieert de methode of de variabele die wordt gebruikt om het schema voor het aangepaste veld te definiëren.

Alle bovenstaande sleutels zijn optioneel, maar als ze niet worden toegevoegd, wordt de mogelijkheid niet toegevoegd. Bijvoorbeeld als u de definieert $ get_callback sleutel maar niet de $ update_callback sleutel, wordt de opvraagfunctionaliteit toegevoegd, maar wordt de update-functionaliteit niet toegevoegd. Als u de. Weglaat $ get_callback sleutel, het veld wordt helemaal niet aan het antwoord toegevoegd.

De register_rest_field () methode werkt door het wijzigen van de $ wp_rest_additional_fields variabel. Deze arrayvariabele bevat geregistreerde velden op objecttypen die moeten worden geretourneerd in het antwoord van de server. Telkens wanneer een veld wordt geregistreerd door de register_rest_field () methode, het wordt toegevoegd aan de $ wp_rest_additional_fields variabel. Het wijzigen van de $ wp_rest_additional_fields variabele handmatig wordt sterk afgeraden.

Aangepaste velden toevoegen aan de respons

We hebben ons vertrouwd gemaakt met de register_rest_field () methode kunnen we nu het antwoord voor de post voorwerp. Een typisch gebruiksscenario is hier de toevoeging van een auteursnaamveld, dat vaak nodig is bij het weergeven van berichten op een indexpagina. Omdat het standaardantwoord dit veld niet bevat, kunnen we de register_rest_field () methode om het in het antwoord op te nemen.

We beginnen met het maken van een eenvoudige plug-in. Dus maak een nieuwe map genaamd rest-respons-modificator in uw / Wp-content / plugins directory. Maak een leeg index.php bestand en plak in de volgende plugindefinitie:

De register_rest_field () methode moet worden geregistreerd in de rest_api_init actie. Daarom creëren we een functie met de naam bs_add_custom_rest_fields () en bind het aan de rest_api_init haak:
Merk op dat de PHP-tags openen  zijn hier niet verplicht, maar ik heb ze toegevoegd, zodat de syntaxis correct is gemarkeerd.
Binnen in de bs_add_custom_rest_fields () functie, we kunnen de register_rest_field () methode om een veld voor auteursnaam op te nemen:
function bs_add_custom_rest_fields () // schema voor het veld bs_author_name $ bs_author_name_schema = array ('description' => 'Naam van de auteur van het bericht', 'type' => 'string', 'context' => array ('view') ); // registratie van het bs_author_name veld register_rest_field ('post', 'bs_author_name', array ('get_callback' => 'bs_get_author_name', 'update_callback' => null, 'schema' => $ bs_author_name_schema)); 
Zoals vermeld in de vorige paragraaf, is het eerste argument in de register_rest_field () methode is de naam van het object waarvoor we het antwoord wijzigen. Omdat we de respons voor de post object, we passeren hetzelfde als het eerste argument.
Het tweede argument in de bovenstaande code is de naam van het veld dat in het antwoord zal verschijnen. Het is altijd een goed gebruik om de naam van een aangepast veld in het antwoord te prefixen om maximale voorwaartse compatibiliteit te garanderen en dat het in de toekomst niet wordt genegeerd door andere plug-ins. Daarom gaan we voorbij bs_author_name in het tweede argument als de $ attribuut van het aangepaste veld.
Het derde en laatste argument in de bovenstaande code is een array voor callback-methoden en het schema. Deze array bevat de naam van de callback-methoden voor het ophalen en bijwerken van het aangepaste veld in de $ get_callback en $ update_callback toetsen respectievelijk. We passeren de bs_get_author_name fungeren als de terughaal-callback-methode. We zullen deze functie binnenkort definiëren.
Voor de $ update_callback sleutel, we passeren nul aangezien dit een alleen-lezen veld is en we de auteursnaam voor een bericht niet hoeven bij te werken.
Voor de $ schema sleutel, geven we een array met de naam $ bs_author_name_schema. Deze array bevat verschillende eigenschappen voor het veld, zoals het gegevenstype, de context en de beschrijving.
Het enige dat we nu moeten definiëren is het bs_get_author_name () functie die zal fungeren als de $ get_callback methode voor ons aangepaste veld. Hieronder staat de code voor deze functie:
/ ** * Callback voor het ophalen van de naam van de auteur * @param array $ object Het huidige post-object * @param string $ field_name De naam van het veld * @param WP_REST_request $ request Het huidige verzoek * @return string De naam van de auteur * / functie bs_get_author_name ($ object, $ field_name, $ request) return get_the_author_meta ('display_name', $ object ['author']); 
De $ get_callback methode ontvangt drie argumenten voor het volgende:
  $ object: Het huidige object. In ons geval is dit de huidige post.
  $ FIELD_NAME: De naam van het aangepaste veld dat wordt toegevoegd.
  $ verzoek: Het aanvraagobject.
 
We gebruiken de $ auteur eigendom van de $ object argument dat de id van de auteur van het bericht bevat. En door de get_the_author_meta () functie, halen we de weergavenaam van de auteur voor de huidige post op en retourneren deze.
Nu het veld is geregistreerd, kunnen we een KRIJGEN verzoek aan de / Wp / v2 / berichten route om te zien of het goed werkt:
Dit is het antwoord in Postman:
Dit nieuw geregistreerde aangepaste veld verschijnt ook in het serverantwoord, samen met het schema, wanneer we een OPTIES verzoek aan de / Wp / v2 / berichten route:
Daarom is een aangepast veld voor de eigenschap author name succesvol geregistreerd. Maar dit veld is alleen-lezen omdat we het niet kunnen bijwerken door een POST verzoek. In het volgende gedeelte registreren we een bewerkbaar veld voor het aantal weergaven.
Een bewerkbaar veld registreren
We registreren nu een aangepast veld voor de telling van het aantal weergaven. We zullen alleen de daadwerkelijke registratie van het veld afhandelen met de WP REST API, waarbij de implementatie weggelaten wordt om het telnummer te verhogen.
Hieronder staat de code voor bs_post_views aangepaste veldregistratie samen met zijn schema:
// schema voor veld bs_post_views $ bs_post_views_schema = array ('description' => 'Aantal weergaven weergeven', 'type' => 'integer', 'context' => array ('view', 'edit')); // registreren van het bs_post_views veld register_rest_field ('post', 'bs_post_views', array ('get_callback' => 'bs_get_post_views', 'update_callback' => 'bs_update_post_views', 'schema' => $ bs_post_views_schema));
De code is vergelijkbaar met degene die we in de vorige sectie hebben geschreven, behalve dat deze nu een callback-methode bevat bs_update_post_views voor de $ update_callback sleutel. Deze functie is verantwoordelijk voor het bijwerken van de waarde van het veld.
De $ context eigendom in de $ bs_post_views_schema schema-array bevat twee waarden voor uitzicht en Bewerk. Opname van bewerkingswaarde in de $ context argument zorgt ervoor dat de bs_post_views veld wordt geretourneerd in de serverreactie nadat het is bijgewerkt.
De callback-methoden voor ophalen en bijwerken zijn als volgt:
/ ** * Terugbellen voor ophalen aantal berichten achteraf * @param array $ object Het huidige berichtobject * @param string $ field_name De naam van het veld * @param WP_REST_request $ request Het huidige verzoek * @return integer Postview count * / function bs_get_post_views ($ object, $ field_name, $ request) return (int) get_post_meta ($ object ['id'], $ field_name, true);  / ** * Terugbellen voor het bijhouden van het aantal weergaven * @param mixed $ value Aantal weergaven aantal weergaven * @param-object $ -object Het object van het antwoord * @param-tekenreeks $ field_name Naam van het huidige veld * @return bool | int * / functie bs_update_post_views ($ value, $ object, $ field_name) if (! $ value ||! is_numeric ($ value)) return;  retourneer update_post_meta ($ object-> ID, $ field_name, (int) $ value); 
De code is vrij eenvoudig omdat deze de get_post_meta () en update_post_meta () methoden voor het ophalen respectievelijk bijwerken van de waarden.
De bs_get_post_views () methode haalt eerst de metawaarde op voor de bs_post_views meta-sleutel en werpt het in een geheel getal voordat het wordt geretourneerd.
De callback-methode is doorgegeven $ update_callback ontvangt drie argumenten voor het volgende:
  $ value: De nieuwe waarde voor het veld.
  $ object: Huidig object van het antwoord.
  $ FIELD_NAME: De naam van het veld dat wordt bijgewerkt.
 
In de bs_update_post_views () methode, controleren we eerst of de doorgegeven waarde niet leeg is en een numerieke waarde is. Zo niet, dan komen we terug zonder iets te doen.
Als de waarde numeriek is, geven we deze door aan de update_post_meta () functie die het in de database opslaat nadat het in een geldig geheel getal is gegooid.
Nadat we het veld met succes hebben geregistreerd, laten we het testen door een KRIJGEN verzoek:
$ GET / wp / v2 / berichten
Hieronder is een voorbeeldantwoord voor het bovenstaande verzoek:
Zoals we in bovenstaande afbeelding kunnen zien, is de huidige waarde van de bs_post_views veld is 0 voor een gegeven bericht. Dit komt omdat het get_post_meta () methode retourneert een lege tekenreeks omdat er geen metawaarde voor de kan worden gevonden bs_post_views meta key en typ-casting een lege string in een integer in PHP resulteert in 0.
We kunnen het updaten bs_post_views veld door een POST verzoek aan de / Wp / v2 / berichten / eindpunt. De JSON-instantie voor het verzoek is als volgt:
"bs_post_views": 4050
Als het verzoek succesvol is, retourneert de server een 200 - OK statuscode samen met het bijgewerkte post-object dat ook het bs_post_views veld:
De bs_post_views aangepast veld is nu bijgewerkt.
Houd er rekening mee dat we een JSON-hoofdgedeelte hebben verzonden langs het verzoek om het veld bij te werken. Het JSON-lichaam bevatte de veldnaam-bs_post_views-met een geheel getal van 4050. Als we proberen een niet-numerieke waarde te verzenden, zeg dan “Abc1234”, het veld zal niet worden bijgewerkt omdat we een voorwaarde controleren voor een numerieke waarde in de bs_update_post_views () callback-methode.
Hieronder vindt u de volledige broncode voor de plug-in:
 'Naam van de auteur van het bericht', 'type' => 'string', 'context' => array ('view')); // registratie van het bs_author_name veld register_rest_field ('post', 'bs_author_name', array ('get_callback' => 'bs_get_author_name', 'update_callback' => null, 'schema' => $ bs_author_name_schema)); // schema voor veld bs_post_views $ bs_post_views_schema = array ('description' => 'Aantal weergaven weergeven', 'type' => 'integer', 'context' => array ('view', 'edit')); // registreren van het bs_post_views veld register_rest_field ('post', 'bs_post_views', array ('get_callback' => 'bs_get_post_views', 'update_callback' => 'bs_update_post_views', 'schema' => $ bs_post_views_schema));  / ** * Callback voor het ophalen van de naam van de auteur * @param array $ object Het huidige post-object * @param string $ field_name De naam van het veld * @param WP_REST_request $ request Het huidige verzoek * @return string De naam van de auteur * / functie bs_get_author_name ($ object, $ field_name, $ request) return get_the_author_meta ('display_name', $ object ['author']);  / ** * Terugbellen voor het ophalen van het aantal berichtweergaven * @param array $ -object Het huidige post-object * @param-tekenreeks $ field_name De naam van het veld * @param WP_REST_request $ -verzoek Het huidige verzoek * @return integer Teveel weergaven * / functie bs_get_post_views ($ object, $ field_name, $ request) return (int) get_post_meta ($ object ['id'], $ field_name, true);  / ** * Terugbellen voor het bijhouden van het aantal weergaven * @param mixed $ value Aantal weergaven aantal weergaven * @param-object $ -object Het object van het antwoord * @param-tekenreeks $ field_name Naam van het huidige veld * @return bool | int * / functie bs_update_post_views ($ value, $ object, $ field_name) if (! $ value ||! is_numeric ($ value)) return;  retourneer update_post_meta ($ object-> ID, $ field_name, (int) $ value); 
Dat is alles voor het wijzigen van serverreacties voor de standaard API-eindpunten. We hebben nauwelijks de oppervlakte bekrast voor het wijzigen van de REST API, omdat deze veel meer flexibiliteit biedt dan alleen het aanpassen van serverreacties. Dit omvat het toevoegen van ondersteuning voor het aangepaste inhoudstype via aangepaste controllers en naamruimten en het registreren van aangepaste routes voor het ontmaskeren en wijzigen van gegevens. We zullen proberen deze geavanceerde onderwerpen in toekomstige artikelen te behandelen.
Pas het begin…
Hier besluiten we onze reis van de introductie van de WP REST API. In deze serie hebben we mooie basisconcepten behandeld, zoals verificatiemethoden en het ophalen, maken en bijwerken van gegevens. In dit laatste deel van de serie hebben we kort gekeken naar de interne klassen van de WP REST API en vervolgens geleerd om serverreacties te wijzigen voor de standaard eindpunten.
Het was nooit de bedoeling van deze serie om elk aspect van de WP REST API te dekken - in feite kan het nooit in een enkele reeks worden bereikt. Maar eerder was het doel van deze serie om je op weg te helpen met deze nieuwe fantastische toevoeging en om je aan te moedigen om alleen te spelen en te experimenteren. Ik hoop dat je deze serie hebt gevonden die zijn uiteindelijke doel vervult.




		
			
	   
	




Code