Share
In het vorige deel van de serie hebben we gekeken hoe we de WP REST API kunnen gebruiken om inhoud van de server op te halen. We hebben geleerd om inhoud op te halen voor verschillende bronnen, inclusief berichten, berichten meta, tags, categorieën, etc. Dit is een krachtige functie omdat deze inhoud overal binnen of buiten WordPress kan worden gebruikt.
We hebben ook geleerd over de OPTIES vraag om zelfdocumentatie van de API door alle routes, hun eindpunten en hun respectieve argumenten op te sommen. Dit vermindert de noodzaak om te vertrouwen op een externe documentatie voor de API en maakt het mogelijk dat wijzigingen eerder snel worden ontdekt in het geval dat de API is bijgewerkt of gewijzigd.
Nu we in de huidige tutorial naar deze functies hebben gekeken, zullen we nu onze aandacht richten op de andere drie bewerkingen van CRUD, d.w.z. het maken, bijwerken en verwijderen van gegevens met behulp van de WP REST API.
In deze tutorial zullen we:
Laten we daarom beginnen met het analyseren van welke bronnen de methoden voor maken, bijwerken en verwijderen ondersteunen met behulp van de WP REST API.
Voordat we rechtstreeks duiken in het maken en bijwerken van gegevens met de WP REST API, moeten we analyseren welke routes de creatie- en updatemethoden ondersteunen. We doen dit door de routes en de methoden eigendom in hun eindpunten. Dit kan gedaan worden door een aparte te sturen OPTIES verzoek om individuele routes, maar een handiger manier is om een KRIJGEN verzoek aan de / Wp-json indexroute zoals we deden in het vorige deel van de serie.
Verzenden van een KRIJGEN verzoek aan de / Wp-json route retourneert een object met alle routes en hun eindpunten in de routes eigendom.
In deze afzonderlijke routes kunnen we controleren of een specifieke bron dit ondersteunt POST, LEGGEN, en DELETE methoden. Laten we beginnen met het analyseren van de berichten hulpbron.
De berichten bron stelt gegevens bloot met de volgende twee routes:
/ wp / v2 / posts / wp / v2 / posts / (? P[\ D] +)
De eerste route verwijst naar de verzameling van het post-object en de bijbehorende methode eigendom is als volgt:
"methoden": ["GET", "POST"],
Deze methoden eigenschap laat zien dat de / berichten routedragers KRIJGEN en POST methoden voor het ophalen respectievelijk creëren van gegevens.
Voor de / Berichten / (? P route, die naar een single verwijst berichten bron, de methoden eigendom is als volgt:
"methods": ["GET", "POST", "PUT", "PATCH", "DELETE"],
Zoals te zien is in de bovenstaande code, is de / Berichten / (? P route ondersteunt de KRIJGEN, POST, LEGGEN, PATCH, en DELETE methoden.
Door beide bovenstaande routes te onderzoeken, kunnen we concluderen dat het / berichten route ondersteunt het ophalen en creëren van bronnen. En de / Berichten / (? P route ondersteunt het ophalen van bronnen evenals bijwerken en verwijderen. Hoewel het de POST methode, ondersteunt deze route het maken van bronnen niet, zoals we in een voorbeeld hieronder zullen zien.
Vandaar dat routes die naar een enkele bron verwijzen niet kunnen worden gebruikt om inhoud te maken, hoewel ze wel de POST methode. Dit komt omdat, voor deze routes, de POST, LEGGEN, en PATCH methoden worden gebruikt om inhoud bij te werken in de WP REST API.
Laten we, om deze paragraaf af te sluiten, de begrippen samenvatten die we hier hebben geleerd:
Accentsconagua
KRIJGEN, POST, en DELETE methoden door een OPTIES verzoek.POST methode.Nadat we verschillende routes hebben geanalyseerd, zijn we nu klaar om inhoud te maken met behulp van de WP REST API, en beginnen we met het verkennen van de berichten hulpbron.
Laten we een bericht maken door een testverzoek van Postman of een andere HTTP-client te verzenden. Om dit te doen, start je je HTTP-client op en verstuur je een POST verzoek aan de / berichten route. Maar denk eraan dat voor het maken, verwijderen en bijwerken van bronnen verificatie als gebruiker is vereist edit_posts rechten. We zullen dus de basisverificatiemethode gebruiken die we in het tweede deel van deze serie hebben geleerd.
Aanvankelijk sturen we een leeg aanvraagformulier mee voor testdoeleinden:
$ POST / wp / v2 / berichten
De server retourneert een 400 - Ongeldig verzoek fout omdat de vereiste argumenten ontbraken in de hoofdtekst van het verzoek. De volgende reactie zal door de server worden geretourneerd:
Het antwoord stelt dat een van beide inhoud, titel, of uittreksel zijn vereist voor het maken van een post-object. Deze argumenten kunnen op verzoek in de verzoekende instantie op een van de volgende drie manieren worden verzonden:
Het is gewoon een kwestie van kiezen om een van deze methoden te gebruiken, en we zullen ze later in deze zelfstudie nader bekijken. Maar laten we nu de eerste methode gebruiken voor het maken van een bericht.
Als u argumenten wilt verzenden als een JSON-object in Postman, schakelt u over naar de Lichaam tab en selecteer de rauw Radio knop. Selecteer vervolgens in de vervolgkeuzelijst aan de rechterkant JSON (toepassing / json) keuze. In het tekstgedeelte hieronder kunt u de JSON-body toevoegen.
Momenteel bevat dit JSON-lichaam slechts één eigenschap voor de titel van de post.
Verzend het verzoek door op te klikken Sturen knop. Als alles goed gaat, zal de server een 201 - Gemaakt status met het nieuw gemaakte berichtobject als het antwoord.
De standaardstatus van dit nieuw gemaakte bericht is droogte. We kunnen het updaten staat, evenals sommige andere eigenschappen, door een andere te verzenden POST, LEGGEN, of PATCH verzoek. De ID van de post die in mijn geval wordt geretourneerd is 232, dus ik stuur een verzoek naar het volgende eindpunt:
$ POST / wp / v2 / posts / 232
Het verzoek om de staat en de inhoud eigendom ziet er als volgt uit:
"status": "publiceren", "inhoud": "Dit is de inhoud van het bericht"
Na het verzenden van het verzoek, zal de server een 200 - OK status, wat betekent dat het bericht met succes is bijgewerkt.
In het bovenstaande voorbeeld hebben we de volgende drie argumenten gevonden om een bericht te maken:
titelstaatinhoudDe volledige lijst met ondersteunde argumenten voor het maken van een bericht kan eenvoudig worden opgehaald OPTIES verzoek als volgt:
$ OPTIES / wp / v2 / berichten
We kunnen dan de args eigendom in de POST methode array.
Nu we hebben geleerd hoe we een bericht kunnen maken en bijwerken, laten we eens kijken naar enkele bronnen waarmee we kunnen werken.
Update: werken met post- en pagina-meta in WP REST API vereist nu een bijbehorende plug-in die beschikbaar is op GitHub door het WP REST API-team.
Post-meta kan worden gemaakt door een POST verzoek om de volgende route:
/ Wp / v2 / berichten / (? P[\ D] +) / meta
Waar (? P is de ID van de bovenliggende post. Ik gebruik de ID van de post die we in de vorige sectie hebben gemaakt 232.
Op dezelfde manier als hoe we een verzoek verzenden om een postobject te maken, kan een JSON-object met twee eigenschappen worden verzonden om een post-meta te maken. Deze twee eigenschappen zijn sleutel en waarde.
"key": "name", "value": "Bilal"
De waarden van de sleutel en waarde eigenschappen zijn naam en Bilal respectievelijk.
Stuur het verzoek en de server zal a retourneren 201 - Gemaakt statuscode, waaruit blijkt dat de meta van het bericht met succes is gemaakt. Het nieuw gemaakte post-metabestand wordt ook geretourneerd in het antwoord:
Houd er rekening mee dat de WP REST API op het moment van schrijven van deze tutorial geen integer-waarden ondersteunt voor het maken van post-meta. Als we een geheel-getalwaarde in het JSON-object proberen te verzenden voor het maken van meta-meta, 400 - Ongeldig verzoek statuscode wordt door de server geretourneerd.
"sleutel": "waarde", "waarde": 12345
Let op de ontbrekende aanhalingstekens rond de waarde 12345. De geretourneerde reactie is als volgt:
Dus alles wat u verzendt met het verzoek om post-meta te maken, moet de tekenreeksindeling hebben.
Tot dusver in deze zelfstudie hebben we het JSON-formaat in de verzoekende instantie gebruikt om bronnen te maken en bij te werken. Laten we eens kijken naar alle opties die de WP REST API biedt voor het maken en bijwerken van gegevens.
De eenvoudigste manier om gegevens langs de aanvraag te verzenden, is deze als URL-parameters te verzenden. Stel je de volgende situatie voor POST verzoek om een post te creëren:
$ POST / wp / v2 / posts? Title = de + title & content = this + is + the + content
De bovenstaande aanvraag verzendt twee parameters naar de server voor de titel en de inhoud van de post.
Evenzo, voor het maken van post-meta voor een bericht met een ID van 232, we gebruiken het volgende POST verzoek:
$ POST / wp / v2 / posts / 232 / meta? Key = name & value = Bilal
De bovenstaande aanvraag zal het volgende meta-object maken:
Deze methode is het meest geschikt wanneer de parameters korte reeksen zijn, zoals in het bovenstaande voorbeeld. Maar naarmate het aantal parameters en de lengte van hun waarden toeneemt, wordt het moeilijk om ze als URL-parameters te beheren.
Met deze methode nemen we argumenten als een sleutel / waarde-paar in een JSON-object om ze door te geven aan het verzoek. Tot nu toe hebben we Postman gebruikt om verzoeken naar de server te verzenden. We zullen nu bekijken hoe we deze methode kunnen implementeren met HTML en jQuery.
Beschouw het volgende eenvoudige formulier dat bestaat uit drie velden voor de titel, staat, en de inhoud:
Wanneer het bovenstaande formulier wordt verzonden, wordt de volgende JavaScript-code (jQuery) uitgevoerd:
var postForm = $ ('# post-form'); var jsonData = function (form) var arrData = form.serializeArray (), objData = ; $ .each (arrData, function (index, elem) objData [elem.name] = elem.value;); keer JSON.stringify terug (objData); ; postForm.on ('submit', functie (e) e.preventDefault (); $ .ajax (url: 'http: // uw-dev-server / wp-json / wp / v2 / berichten', methode: 'POST', gegevens: jsonData (postForm), crossDomain: true, contentType: 'application / json', beforeSend: function (xhr) xhr.setRequestHeader ('Authorization', 'Basic username: password');, success: function (data) console.log (data);, error: function (error) console.log (error);););Na verzending van het bovenstaande formulier sturen we een AJAX-verzoek naar de / Wp / v2 / berichten route. De jsonData () methode accepteert een jQuery-instantie van het HTML-formulier en converteert de gegevens naar JSON-indeling. Deze JSON-gegevens worden vervolgens gebruikt in de gegevens eigendom van de $ .Ajax () methode. Bovendien hebben we het inhoudstype ingesteld op application / json door de contentType eigendom.
Voordat we het verzoek verzenden, stellen we de header in om de machtiging header voor het gebruik van de standaard authenticatiemethode. We hebben in de tweede helft van deze serie al geleerd om de basisverificatiemethode in te stellen en te gebruiken.
Ten slotte wordt het verzoek verzonden naar de / Wp / v2 / berichten route en er wordt een nieuw bericht gemaakt. Dit zojuist gemaakte post-object wordt door de server als antwoord geretourneerd en we loggen het gewoon in de console in de succes() methode.
Het bovenstaande voorbeeld demonstreert het gebruik van JSON-indeling om gegevens langs het verzoek te verzenden. De bron van dit JSON-object kan van alles zijn behalve een HTML-formulier, afhankelijk van de architectuur van uw toepassing.
Houd er rekening mee dat het mogelijk nodig is om de bovenstaande code in te stellen om correct te werken Access-Control-Sta-Headers koptekstveld om de machtiging en Content-Type waarden. Dit kan gedaan worden door de volgende code toe te voegen aan je WordPress's .htaccess het dossier:
Header set Access-Control-Allow-Headers "Inhoudstype, autorisatie"
Laten we nu kijken naar het verzenden van gegevens via HTML-formulieren.
De laatste manier om gegevens langs het verzoek te verzenden, is door HTML-formulieren te gebruiken. Deze formulieren moeten velden bevatten met de naam attribuut. De naam attribuut dient als een argumentnaam zoals titel, staat, inhoud, enz. De waarden van deze velden dienen als de waarde van deze argumenten.
We kunnen hetzelfde HTML-formulier gebruiken dat in het vorige voorbeeld is gemaakt en vervolgens de volgende code gebruiken om een nieuw bericht te maken:
var postForm = $ ('# post-form'); postForm.on ('submit', functie (e) e.preventDefault (); $ .ajax (url: 'http: // uw-dev-server / wp-json / wp / v2 / berichten', methode: 'POST', data: postForm.serialize (), crossDomain: true, beforeSend: function (xhr) xhr.setRequestHeader ('Autorisatie', 'Basic username: password');, success: function (data) console. log (data);););De bovenstaande code is hetzelfde als in het vorige voorbeeld, behalve dat we de jsonData () methode en we verzenden nu de formuliergegevens in tekenreeks met behulp van jQuery's serialize () methode. De bovenstaande jQuery-code gebruikt de standaard application / x-www-form-urlencoded inhoudstype dat de gegevens verzendt in de vorm van een gigantische tekenreeks met argumenten gescheiden door de & teken en hun waarden worden toegewezen met behulp van de = teken. Dit lijkt enigszins op het verzenden van gegevens als URL-parameters, behalve dat het geen gegevens blootlegt. Dit is een efficiënte manier om gegevens te verzenden als de gegevens alleen alfanumerieke tekens bevatten.
Om binaire (niet-alfanumerieke) gegevens te verzenden, gebruiken we de multipart / form-data inhoudstype. Deze methode kan worden gebruikt als we afbeeldingen of andere bestanden moeten uploaden met de WP REST API.
Om formuliergegevens in Postman te verzenden, kunt u overschakelen naar de Lichaam tab en gebruik vervolgens de form-data of x-www-form-urlencoded keuze.
Argumenten kunnen vervolgens worden gedefinieerd in sleutel / waardeparen om het verzoek te verzenden.
Gedetailleerde informatie over verschillende vormen is te vinden in de W3C-specificaties.
multipart / form-data InhoudstypeNu we naar de hebben gekeken x-www-form-urlencoded formuliertype, dat gegevens in de vorm van een tekenreeks verzendt, laten we beginnen met het verkennen van een meer geavanceerd formuliercoderingstype, d.w.z.. multipart / form-data.
De multipart / form-data inhoudstype wordt gebruikt bij het verwerken van binaire gegevens en kan daarom worden gebruikt om afbeeldingen of andere bestandstypen naar de server te uploaden.
In het volgende voorbeeld gebruiken we een eenvoudig HTML-formulier dat bestaat uit een input [type =”file”] en een beetje jQuery om afbeeldingen naar de server te uploaden met behulp van de / Wp / v2 / media route.
Beschouw het volgende HTML-formulier:
Het volgende JavaScript wordt uitgevoerd wanneer het bovenstaande formulier wordt verzonden:
var imageForm = $ ('# image-form'), fileInput = $ ('# file'), formData = new FormData (); imageForm.on ('submit', function (e) e.preventDefault (); formData.append ('file', fileInput [0] .files [0]); $ .ajax (url: 'http: // your-dev-server / wp-json / wp / v2 / media ', methode:' POST ', data: formData, crossDomain: true, contentType: false, processData: false, beforeSend: function (xhr) xhr.setRequestHeader ( 'Autorisatie', 'Basis gebruikersnaam: wachtwoord');, succes: functie (gegevens) console.log (data);, error: function (error) console.log (error););) ;Hier krijgen we eerst een jQuery-instantie van het formulier en het invoerveld. Vervolgens initialiseren we een nieuwe FormData voorwerp. De FormData interface biedt een manier voor het samenstellen van een reeks formuliervelden met sleutel / waarde-paren en gebruikt dezelfde indeling als de multipart / form-data formuliercoderingstype.
Wanneer het formulier wordt ingediend, voorkomen we dat het wordt ingediend door het .voorkom standaard() methode op het gebeurtenisobject. Vervolgens voegen we een nieuw veld toe aan de formdata bijvoorbeeld met behulp van de .toevoegen () methode. De .toevoegen () methode accepteert twee argumenten voor de naam en de waarde van het veld. De WP REST API dwingt de naam attribuut van het bestandsinvoerveld dat moet zijn het dossier. Daarom hebben we het eerste argument - de naam-zijn het dossier, en voor het tweede argument passeren we een bestandsblob-object door te verwijzen naar het invoerelement.
Standaard worden de gegevens doorgegeven aan de gegevens eigendom van de jQuery.ajax () methode wordt verwerkt in een querystring. Omdat we hier beeldbestanden uploaden, willen we niet dat dit gebeurt en daarom hebben we de data verwerken eigendom aan vals. We hebben ook de contentType eigendom aan vals voorkomen application / x-www-form-urlencoded wordt verzonden als het standaard inhoudstype naar de server.
En ten slotte hebben we de machtiging header om onszelf te authenticeren als een gebruiker met edit_posts privileges.
Zorg ervoor dat u het bovenstaande script uitvoert vanuit een server. Als alles goed gaat en het bestand wordt geüpload, retourneert de server het nieuw gemaakte media-object.
Deze afbeelding kan vervolgens worden ingesteld als een aanbevolen afbeelding voor een bericht.
Nadat we nauwkeurig hebben gekeken naar manieren om bronnen te maken en bij te werken met behulp van de WP REST API, laten we zien hoe we deze kunnen verwijderen.
Gegevens verwijderen met de WP REST API is net zo eenvoudig als het verzenden van een DELETE verzoek om een bepaalde bron.
Als we een bericht met een ID van moeten verwijderen 10, we sturen het volgende DELETE verzoek:
$ DELETE / wp / v2 / posts / 10
Hiermee wordt de post naar de prullenbak verplaatst, maar niet permanent verwijderd. Voor het permanent verwijderen van een bericht gebruiken we de dwingen argument:
$ DELETE / wp / v2 / posts / 10? Force = true
Merk op dat de dwingen argument is vereist wanneer een resource wordt verwijderd die geen trashing ondersteunt. Voorbeelden van dergelijke bronnen zijn post-meta en media.
Dat gezegd hebbende, concluderen we nu het huidige deel van de serie.
In deze lange zelfstudie hebben we gekeken naar het maken, bijwerken en verwijderen van verschillende soorten bronnen met behulp van de WP REST API. We hebben geleerd over verschillende manieren om gegevens langs het verzoek te verzenden, waaronder het verzenden van gegevens als URL-parameters, in JSON-indeling en met behulp van formulieren. Aan het einde van de zelfstudie leerden we over het verwijderen van bronnen door een DELETE verzoek.
In het volgende en laatste deel van de serie zullen we meer te weten komen over de interne structuur van de WP REST API en zijn klassen. We zullen ook leren om de API uit te breiden om serverreacties te wijzigen. Tot ziens in het volgende deel van de serie - stay tuned ...
