Share
Odată cu lansarea sa în 2003, WordPress a crescut de la o platformă de blogging la un sistem complet de gestionare a conținutului. În ultimii ani, a ajuns să se maturizeze suficient pentru a satisface nevoia unei marea majoritate a publicului online și acesta este motivul pentru care operează mai mult de 20% din web astăzi.
Cu multe funcții noi adăugate la WordPress, una dintre cele mai recente adăugiri este API-ul REST care permite altor aplicații și platforme să interacționeze cu WordPress. Este un plus revoluționar care va ajuta dezvoltatorii să creeze aplicații personalizate și sisteme integrate cu WordPress. Având în vedere că oferă posibilitatea de a adăuga și de a prelua conținut de la orice alt client sau site, fără a fi nevoie să aveți WordPress instalat pe acel site, WordPress va permite să fie utilizat cu orice limbaj de programare sau platformă.
În această serie cu mai multe părți vom examina API-ul WP REST și modul în care acesta ar putea fi folosit pentru a crea experiențe de utilizator care altfel erau imposibile sau cel puțin dificile cu WordPress. Vom analiza mai întâi conceptele de bază, inclusiv REST și JSON, și apoi vom explora opțiunile disponibile pentru noi prin WP REST API.
Mai jos sunt câteva resurse pe care le-am găsit utile pentru conceptele de bază, inclusiv HTTP, REST și JSON. Vă recomand să vă uitați la ele dacă nu ați făcut-o deja:
Înainte de a începe cu subiectul nostru, să aruncăm o scurtă privire asupra a ceea ce este de fapt arhitectura REST și să ne familiarizăm și cu terminologia sa comună.
Pentru a începe cu subiectul, să aruncăm o privire la REST (Reprezentaționale Slita Ttransfer) arhitectura și unele dintre cele mai comune concepte. Înțelegerea acestora este esențială atunci când dezvoltați aplicații utilizând stilul arhitectural REST.
REST este un stil arhitectural care ajută la crearea și organizarea unui sistem distribuit. Descrie web-ul ca o aplicație hipermedia distribuită a cărei resurse conectate comunică prin schimbarea reprezentărilor resursă stat.
Resursele reprezintă principalele elemente ale arhitecturii REST. De fapt, acestea sunt principalele elemente de bază ale web-ului în sine, în măsura în care web-ul este uneori denumit "orientat spre resurse".
Când vorbim despre WordPress, aceste resurse sunt entități discrete precum postări, pagini, comentarii, utilizatori și tipuri personalizate de posturi etc. Pentru a interacționa cu resursele, URIuri (Uniform Resource Identifier) și, după cum sugerează și numele, este un identificator pentru o resursă.
Un serviciu RESTful tratează URI-urile ca modalitate principală de abordare a unei resurse de bază. Aceste resurse pot avea mai multe reprezentări. De exemplu, un fișier imagine ar putea fi disponibil în formate .JPG, .GIF sau .PNG. Relația dintre resurse și URI este una-la-multe. Un URI poate indica doar o anumită resursă, dar o resursă poate avea mai mult de un URI.
Lista tuturor resurselor suportate în prezent de API-ul WP REST este prezentată mai jos:
Putem efectua diferite acțiuni pe aceste resurse folosind verbale HTTP.
Un API REST permite practic efectuarea operațiilor CRUD (Create Read Update Delete) asupra resurselor utilizând HTTP. În acest scop, REST folosește un set limitat de verbe de solicitare HTTP care sunt după cum urmează:
Accentsconagua
OBȚINE: Folosit pentru a citi sau a recupera o resursăPOST: Utilizat pentru a crea o nouă resursăA PUNE: Utilizat pentru a actualiza o resursăȘTERGE: Se utilizează pentru a șterge o resursăCAP: Utilizat pentru a verifica dacă există o resursă fără a reveni la reprezentarea acesteiaOPȚIUNI: Utilizat pentru a prelua toate verbele acceptate de o resursăÎntr-un serviciu RESTful, aceste verbe au o semnificație bine definită. Primele patru verbe din lista de mai sus fac parte din acțiunile CRUD, adică preiau, creează, actualizează și șterg entități. Ultimele două verbe ajută un client să determine dacă există o resursă și ce verbe HTTP sunt disponibile pentru ca ea să efectueze operații ulterioare.
A OBȚINE cererea returnează informații și este idempotent adică un client poate suna de mai multe ori, dar nu va afecta starea unei resurse.
Pentru a obține toate postările utilizând API-ul WP REST, folosim următoarele punct final:
GET wp / v2 / postări
Punctul final de mai sus va returna a Colectie din toate entitățile postului.
Când se declanșează următorul parametru final, acesta returnează un anumit parametru entitate adică un post care are un id de 100:
GET wp / v2 / posturi / 100
A POST cererea creează o entitate nouă și o A PUNE solicită înlocuirea acelei entități cu o nouă versiune.
Următoarele POST cererea poate fi utilizată pentru a crea un post nou (trimiterea de-a lungul corpului de solicitare pe care o vom examina în partea ulterioară a seriei) utilizând API-ul WP REST:
POST wp / v2 / postări
Și următoarele A PUNE cererea va actualiza o postare care are un id de 100:
PUT wp / v2 / posturi / 100
A ȘTERGE cererea șterge o resursă din sistem. Acest tip de solicitare, împreună cu A PUNE cererea este repetabilă, ceea ce înseamnă că apelarea acestor metode va avea același efect asupra sistemului. De exemplu, dacă apelați a A PUNE solicitați de mai multe ori o resursă (cu aceleași argumente), rezultatul va fi același. Același lucru este valabil și pentru a ȘTERGE cerere. Ștergerea unei resurse de mai multe ori va avea același efect, adică resursa va fi ștearsă (sau o eroare ar fi returnată în cazul unei resurse deja șterse).
În plus față de aceste acțiuni CRUD, un serviciu RESTful oferă încă două verbe care sunt OPȚIUNI și CAP. Aceste verbe vin la îndemână atunci când un client are nevoie să verifice ce resurse sunt disponibile pe sistem și ce acțiuni suportă, oferind astfel o modalitate de auto-documentare pentru ca clientul să exploreze în continuare sistemul și să efectueze acțiuni. Vom vedea aceste două metode în acțiune mai târziu în acest tutorial.
Rețineți că în primul exemplu de mai sus am folosit următoarele punct final:
GET wp / v2 / postări
Punctele finale sunt funcții care sunt disponibile prin API și efectuează mai multe acțiuni, cum ar fi preluarea postărilor (pe care le facem mai sus), crearea unui nou utilizator sau actualizarea unei postări meta. Alternativ, putem spune că un punct final declanșează o metodă care efectuează o sarcină specifică. Aceste puncte finale depind de verbul HTTP asociat cu acestea. În exemplul de mai sus, folosim verbul GET pentru a prelua toate postările.
traseu pentru obiectivul de mai sus este următorul:
wp / v2 / mesaje
Un traseu este, în principiu, un nume pentru a accesa punctul final. O rută poate avea mai multe puncte finale bazate pe verbe HTTP. Deci, ruta de mai sus are următoarea valoare finală pentru a crea un post nou:
POST wp / v2 / postări
Acest parametru, atunci când este declanșat cu parametrii furnizați, va crea o entitate post nouă.
Luați în considerare următorul traseu:
wp / v2 / mesaje / 100
Această rută indică entității Post care are un id de 100. Are următoarele trei puncte finale:
GET wp / v2 / posturi / 100: Care poate fi folosit pentru a prelua postul având un id de 100. Acesta declanșează get_item () metodă.PUT wp / v2 / posturi / 100: Poate fi folosit pentru a actualiza postul având un id de 100. Acesta declanșează update_item () metodă.Ștergeți wp / v2 / posts / 100: Sterge postul având un id de 100. Acesta declanșează Sterge articolul() metodă.Vom afla mai multe despre intervalele WP REST API, structura clasei și metodele interne din ultima parte a acestei serii.
Să ne actualizăm acum cunoștințele despre câteva coduri comune de răspuns HTTP și ce înseamnă acestea.
Un server răspunde la o solicitare returnând un răspuns care conține un cod de stare HTTP. Aceste coduri sunt numere cu semnificații predefinite asociate cu acestea. De exemplu, oricine folosește webul ar fi familiarizat cu 404 codul de stare care sintetizează că resursa, utilizatorul căuta, nu a fost găsită.
Răspunsul serverului depinde, de asemenea, de tipul verbului HTTP sau de metoda pe care o folosim în cererea trimisă, așa cum vom vedea în continuare.
Următoarele sunt câteva coduri comune de răspuns HTTP împreună cu semnificațiile acestora pe care le vom întâlni când lucrăm cu WP REST API și semnificațiile acestora:
- OK: Înseamnă că cererea a fost încheiată cu succes și serverul a returnat răspunsul. De obicei, reveniți după un succes OBȚINE cerere.201 - Creat: De obicei returnat după un succes POST cerere. Rezumă că resursa a fost creată.400 - Cerere rea: Se returnează de la server atunci când o solicitare a fost trimisă cu câțiva parametri lipsă sau invalizi. De obicei, returnat ca răspuns la POST sau A PUNE cereri.401 - Neautorizat: Înseamnă că utilizatorul nu a fost autorizat să efectueze anumite acțiuni. De exemplu, un utilizator a încercat să creeze sau să șteargă o resursă fără a furniza informații de autentificare.403 Interzis: Înseamnă că serverul a înțeles solicitarea, dar a refuzat să îl completeze din cauza autentificării. Se întâmplă atunci când un utilizator oferă acreditări de autentificare, dar nu are drepturi suficiente pentru a efectua acțiunea.404 Nu a fost gasit: Cele mai multe (in) celebre din toate codurile de stare. Rezumă că nu a fost găsită o resursă pe care utilizatorul o caută.405 - Metoda nu este permisă: Înseamnă că un verb HTTP furnizat în cerere nu a fost acceptat de resursă. Un exemplu ar putea fi un utilizator care încearcă să actualizeze o resursă numai pentru citire.410 - Plecat: Înseamnă că o resursă a fost mutată într-o altă locație. Un exemplu ar putea fi încercarea de a șterge o resursă deja șters care a fost mutată în coșul de gunoi.500 Eroare internă a server-ului: Se returnează atunci când un server întâlnește o condiție neașteptată și nu finalizează solicitarea.501 - Neaplicat: Înseamnă că serverul nu suportă funcționalitatea pentru a finaliza solicitarea. Apare de obicei când un server primește o metodă de solicitare pe care nu o recunoaște.Vom analiza mai atent aceste verbale HTTP și codurile de răspuns când vom începe să lucrăm cu API-ul. Dar, înainte de aceasta, să aruncăm o privire asupra motivelor pentru utilizarea REST API cu WordPress și a avantajelor pe care le oferă dezvoltatorului și utilizatorului. La urma urmei, am nevoie ca tu să fii cu adevărat interesat să urmezi împreună cu mine în timpul acestei serii.
REST și JSON împreună oferă un mecanism pentru crearea de aplicații puternice utilizând back-end-ul WordPress. Cele mai bune exemple sunt aplicațiile mobile care necesită schimbul de date între client (dispozitiv) și server. Ținând cont de limitările de lățime de bandă atunci când utilizează date celulare, JSON oferă o alternativă ușoară la soluțiile bazate pe XML.
Din moment ce JSON este un format bazat pe text pentru stocarea datelor, acesta poate fi utilizat fără cusur cu majoritatea limbajelor de programare. Prin urmare, JSON servește ca un conector global atunci când schimbă date între diferite platforme care este la fel de ușor de citit atât de mașini cât și de oameni.
Cu utilizarea API ca cea discutată, conținutul site-ului dvs. WordPress nu se limitează la el însuși, ci poate fi accesat de alte site-uri și clienți. Întrucât API expune anumite părți ale funcționalității interne, clienții de la distanță pot interacționa cu site-ul dvs. pentru a actualiza sau crea conținut nou. De asemenea, permite să preluați conținut de pe un site WordPress existent și să îl afișați pe un alt site.
Odată cu creșterea cadrelor JavaScript de pe partea clientului, cum ar fi Angular, Backbone sau Ember, a devenit posibil să se folosească una dintre acestea pentru a crea experiențe bogate în utilizatori în timp ce încă se utilizează back-end-ul WordPress.
Cu aceasta a spus, unele cazuri posibile de utilizare pentru WP REST API sunt:
Se deschide într-adevăr o nouă lume a posibilităților, unde singura limită este imaginația cuiva.
Înainte de API-urile REST bazate pe JSON, API-ul utilizat pentru a interacționa de la distanță cu WordPress a fost API XML-RPC care face parte din nucleul WordPress. Problema cu XML este că nu este la fel de ușor ca formatul JSON și parsarea lui nu este eficientă. Traversarea XML este, de asemenea, o mare durere de cap, în timp ce traversarea unui obiect JSON este la fel de ușor ca manipularea unui obiect JavaScript nativ.
Primul plugin REST API vreodată introdus pentru WordPress a fost JSON API care a fost lansat în 2009. A fost construit la Muzeul de Artă Modernă pentru blogul lor Inside / Out. Acest front-end al blogului a fost alimentat de Ruby on Rails, pentru a prelua mesajele și a adăuga comentarii la backend-ul WordPress, a fost dezvoltat un API. Acest plugin oferă interfețe pentru recuperarea conținutului și trimiterea de comentarii către backend-ul WP. Deși nu este actualizat de mai mult de doi ani, acest plugin este încă prezent în depozitul oficial și este suspectat de apariție.
În afară de pluginul JSON API, WordPress.com a furnizat deja JSON API prin pluginul JetPack.
API-ul WP REST, așa cum îl cunoaștem astăzi, este un plug-in feature care a fost propus de Ryan McCue ca parte a programului GsoC (Google Summer of Code) 2013. Nu este încă inclus (complet) în nucleul WordPress într-o versiune viitoare. Actuala versiune 2.0 a plugin-ului este în stare beta și este parțial inclusă în core-ul WordPress în versiunea 4.4. Este un proiect condus de comunitate condus de Ryan McCue și Rachel Baker. Pagina de depozitare oficială a plugin-ului este localizată pe GitHub, iar documentația oficială poate fi găsită pe site-ul său.
După cum sa menționat mai sus, API-ul WP REST este în prezent în modul plugin și este dezvoltat activ pe GitHub. Acesta a fost inclus partial in WordPress core in versiunea 4.4 si Ryan a descris planul in propunerea sa de fuziune pe WordPress.org.
Conform propunerii de fuziune, WP REST API va fi încorporat în miezul WP în două etape, după cum urmează:
Conform propunerii, în etapa inițială, doar codul nivelului de infrastructură va fi fuzionat în nucleul WP din versiunea 4.4. Acest cod de infrastructură este baza reală a API-ului WP REST deoarece include serializarea / deserializarea JSON, legarea, încorporarea și cel mai important dintre toate - stratul de rutare care acționează API-ul. Acest cod nu include punctele finale și clasele lor de controlor, dar oferă o bază pentru construirea API-urilor în WordPress.
La momentul scrisului, această stare a fost finalizată, iar codul de infrastructură a fost îmbinat în corelația WordPress în versiunea 4.4.
Punctele finale pentru postări, pagini, utilizatori și taxonomii, etc., vor fi încorporate în nucleul WP din versiunea 4.5, adică o versiune mai târzie decât îmbinarea codului de infrastructură. Punctele finale sunt ceea ce face API util pentru clienții generali. Acestea includ multă complexitate, incluzând maparea datelor externe în format JSON la tipurile de date native WordPress și invers. Acestea reprezintă codul de două treimi al API în sine, cu aproximativ 5500 de linii.
Strategia de aici este de a construi încrederea dezvoltatorilor în API, oferind mai întâi codul de infrastructură în nucleu. Acest lucru ar permite dezvoltatorilor de teme și plugin-uri să creeze API-uri personalizate pentru a fi incluse în temele și pluginurile lor. Dar, deoarece obiectivele finale nu vor fi incluse în acest stadiu, acest lucru ar limita inițial utilitatea API-ului.
Diferența dintre cele două versiuni le-ar oferi echipei de bază a WP suficient timp pentru a revizui obiectivele API.
Un alt avantaj pe care API-ul WP REST l-ar aduce comunității WordPress este utilizarea GitHub în versiunea care controlează proiectul. Deoarece toate contribuțiile la WordPress sunt realizate prin intermediul SVN și Trac, echipa WP REST API este destul de încrezătoare în îmbunătățirea procesului de contribuție prin depășirea decalajului dintre Trac și GitHub.
După îmbinarea API-ului în nucleu, putem spera să vedem evoluții rapide în alte domenii, inclusiv autentificarea OAuth 1.0a.
Pentru a începe testarea cu API-ul WP REST vom avea nevoie de un client HTTP care va fi folosit pentru a trimite cereri către server și pentru a vedea răspunsul. Este o chestiune de alegere, dar voi folosi Postman pentru Google Chrome în această serie. Alte alternative la Postman sunt:
Postmanul ne permite să creăm rapid cereri HTTP de diferite metode, să vedem răspunsul de la server și configurația de testare pentru autentificare. Toate aceste caracteristici vor fi extrem de la îndemână atunci când lucrați cu WP REST API.
Următorul lucru pe care trebuie să-l avem pe serverul nostru este WP-CLI. Cu WP-CLI, putem gestiona de la distanță instalarea noastră WordPress din interiorul consolei fără a fi nevoie să deschideți fereastra browserului. Va trebui să folosim WP-CLI în următoarea parte a acestei serii când setăm autentificarea OAuth 1.0a. Puteți găsi instrucțiunile de instalare pe site-ul oficial.
În afară de un client HTTP și WP-CLI, avem nevoie și de date demo pentru instalarea WordPress. Vă sugerăm să verificați Testul unității tematice (XML) sau pluginul Creator de date demo care permite crearea mai multor postări, pagini și utilizatori.
La momentul elaborării acestui tutorial, actuala versiune stabilă este 1.2.2, care poate fi găsită în repozitoriul oficial. În această serie, vom lucra cu versiunea 2.0, deoarece a fost re-scrisă de la bază și conține multe schimbări de rupere. Puteți lua versiunea 2 beta din pagina oficială a plugin-ului sau din depozitul GitHub.
Rețineți că nu este foarte recomandat să instalați versiunea curentă beta în mediul dvs. de producție. Am creat un mediu local WordPress și vă recomand să faceți acest lucru pentru scopuri de dezvoltare și testare.
Pentru a instala pluginul din depozitul GitHub, deschideți terminalul și trageți plugin-ul după ce ați intrat în telefonul dvs. / Wp-content / plugins / director:
$ git trageți https://github.com/WP-API/WP-API.git
Pluginul va fi descărcat în / WP-API / director.
Puteți să o activați de la administratorul dvs. WordPress pentru a continua testarea cu acesta.
Pentru ca pluginul WP REST API să funcționeze, trebuie să activați destul de permalinks cu WordPress. Se presupune că deja știți să efectuați această acțiune de bază. Dacă nu, nu vă faceți griji ca WordPress.org te-a acoperit.
După instalarea pluginului, putem evalua disponibilitatea API-ului pe serverul nostru. Nu ne limităm la utilizarea API-ului numai pe site-ul nostru, de fapt îl folosim pe orice site care a instalat și activat. Pentru a verifica dacă există API pe alte site-uri, putem trimite o solicitare HEAD site-ului ca următoarele folosind clientul dvs. HTTP:
$ HEAD http://someothersite.com/
Acest lucru va returna în antetul de răspuns ceva de felul următor:
Legătură antetul punctează ruta rădăcină a API-ului WP care, în cazul nostru, este următoarea:
http: // LocalServer / WordPress-api / wp-JSON /
API-ul poate fi, de asemenea, descoperit prin intermediul browserului JavaScript (sau jQuery) prin interogarea DOM pentru cea potrivită cum ar fi:
(funcția ($) var $ link = $ ('link [rel = "https://github.com/WP-API/WP-API"];) var api_root = $ link.attr (' href ' ;) (jQuery);De aici putem începe să preluăm conținutul de pe site prin API-ul WP REST. Rețineți că numai cererile autentificate pot edita sau actualiza conținutul de pe site și salvez subiectul setării autentificării pentru următoarele două părți din această serie.
În această parte introductivă a seriei am învățat destul de multe despre arhitectura REST, WP REST API și HTTP în sine. Am analizat mai întâi conceptele de bază cum ar fi ce arhitectură REST și cum poate ajuta dezvoltatorii să creeze aplicații mai bune. Apoi am aflat despre HTTP, verbele și tipurile de răspuns. Ne-am uitat de asemenea la istoricul scurt despre API-urile din WordPress și despre modul în care WP REST API este diferit de predecesorii săi.
În ultima parte a acestui tutorial, am instalat plugin-ul de la GitHub. După aceea, ne-am familiarizat cu a CAP care poate fi utilizată pentru a determina disponibilitatea API-ului pe serverul nostru, precum și pe alte servere.
După ce am creat mediul de lucru de bază, suntem gata să lucrăm cu caracteristicile pe care WP REST API le oferă. În următoarea parte a seriei, vom căuta modalități de a configura metode de autentificare care sunt acceptate de API. Aceste metode de autentificare vor fi necesare atunci când trimiteți solicitarea de a prelua, crea, actualiza sau șterge conținut. Stați așa.
