Este mar\u021bi diminea\u021ba. Cafeaua abia \u0219i-a f\u0103cut efectul, iar tu deschizi laptopul, gata de o nou\u0103 zi productiv\u0103. Dar ceva e \u00een neregul\u0103. Alertele se aprind ca un brad de Cr\u0103ciun \u00een iulie. Serviciul X, de care depinde jum\u0103tate din aplica\u021bia ta, a picat. Sau, mai r\u0103u, r\u0103spunde cu erori pe care nu le-ai mai v\u0103zut niciodat\u0103. Panic\u0103. Dup\u0103 c\u00e2teva zeci de minute de investiga\u021bii frenetice, descoperi cauza: o serie de modific\u0103ri API<\/b> neanun\u021bate, implementate peste noapte de c\u0103tre furnizor. Sun\u0103 cunoscut? Din p\u0103cate, este un scenariu mult prea comun \u00een lumea dezvolt\u0103rii software, o lume interconectat\u0103 prin mii de fire invizibile numite API-uri. Gestionarea acestor schimb\u0103ri este mai mult dec\u00e2t o sarcin\u0103 tehnic\u0103; este o art\u0103. O art\u0103 a supravie\u021buirii digitale.<\/p>\nIntroducere \u00een Lumea Modific\u0103rilor API: De Ce Sunt Inevitabile?<\/h2>\n
Schimbarea este singura constant\u0103, iar \u00een tehnologie, aceast\u0103 axiom\u0103 este amplificat\u0103 de o mie de ori. API-urile (Application Programming Interfaces) sunt coloana vertebral\u0103 a serviciilor moderne, permi\u021b\u00e2nd aplica\u021biilor s\u0103 comunice \u00eentre ele. Dar, la fel ca orice produs software, ele trebuie s\u0103 evolueze. A crede c\u0103 un API va r\u0103m\u00e2ne static pentru totdeauna este o naivitate costisitoare. Aceste modific\u0103ri API<\/b> nu sunt un defect, ci un semn de via\u021b\u0103, o dovad\u0103 c\u0103 produsul din spate se \u00eembun\u0103t\u0103\u021be\u0219te, se securizeaz\u0103 \u0219i se adapteaz\u0103 la noi cerin\u021be. Adev\u0103rata provocare nu este existen\u021ba lor, ci felul \u00een care le abord\u0103m. Un ghid complet pentru adaptarea la modific\u0103ri API<\/b> este esen\u021bial. Problema nu este c\u0103 ele exist\u0103, ci cum le gestion\u0103m. Sau, mai exact, cum supravie\u021buim impactului lor.<\/p>\nDefinirea Modific\u0103rilor API \u0219i Rolul Lor<\/h3>\n
Pe scurt, orice schimbare adus\u0103 contractului unui API reprezint\u0103 o modificare. Acest “contract” este setul de reguli \u0219i specifica\u021bii pe care o aplica\u021bie client trebuie s\u0103 le urmeze pentru a interac\u021biona cu API-ul: endpoint-uri, metode (GET, POST), parametri, structuri de date, coduri de r\u0103spuns. Rolul acestor modific\u0103ri API<\/b> este, teoretic, unul pozitiv: ad\u0103ugarea de noi func\u021bionalit\u0103\u021bi, optimizarea performan\u021bei, corectarea unor bug-uri sau, cel mai important, consolidarea securit\u0103\u021bii. F\u0103r\u0103 ele, am fi bloca\u021bi cu tehnologii \u00eenvechite \u0219i vulnerabile.<\/p>\nMotivele din Spatele Evolu\u021biei Constant\u0103 a API-urilor<\/h3>\n
De ce se schimb\u0103 API-urile? Motivele sunt diverse \u0219i, de cele mai multe ori, perfect legitime. Unul dintre motivele principale este ad\u0103ugarea de noi capabilit\u0103\u021bi. Business-ul evolueaz\u0103, cerin\u021bele clien\u021bilor se schimb\u0103, iar API-ul trebuie s\u0103 reflecte aceste noi realit\u0103\u021bi. Apoi, exist\u0103 optimizarea. Poate c\u0103 un endpoint este prea lent sau consum\u0103 prea multe resurse; o refactorizare poate duce la modific\u0103ri API<\/b> menite s\u0103 \u00eembun\u0103t\u0103\u021beasc\u0103 eficien\u021ba. Securitatea este un alt factor critic. Descoperirea unei vulnerabilit\u0103\u021bi poate impune o schimbare imediat\u0103 \u0219i, uneori, drastic\u0103. \u00cen final, exist\u0103 \u0219i “cur\u0103\u021benia de prim\u0103var\u0103”: refactorizarea codului intern, care poate duce la simplificarea sau reorganizarea API-ului public, necesit\u00e2nd modific\u0103ri API<\/b> pentru o mai bun\u0103 coeren\u021b\u0103.<\/p>\nClasificarea Modific\u0103rilor API: De la Inofensive la Disruptive<\/h2>\n
Nu toate schimb\u0103rile sunt create egal. Unele sunt simple ad\u0103ugiri, \u00een timp ce altele pot d\u0103r\u00e2ma \u00eentregi ecosisteme digitale. S\u0103 fim serio\u0219i, \u00een\u021belegerea acestei diferen\u021be este crucial\u0103 pentru orice dezvoltator care vrea s\u0103 doarm\u0103 lini\u0219tit noaptea.<\/p>\n
Acestea sunt schimb\u0103rile “bune”. O modificare compatibil\u0103 cu versiunile anterioare (backward-compatible) este o ad\u0103ugire care nu stric\u0103 implement\u0103rile existente. De exemplu, ad\u0103ugarea unui nou c\u00e2mp op\u021bional \u00een r\u0103spunsul JSON sau introducerea unui nou endpoint. Clien\u021bii existen\u021bi pot ignora aceste ad\u0103ugiri \u0219i vor continua s\u0103 func\u021bioneze f\u0103r\u0103 probleme. Aceste modific\u0103ri API<\/b> sunt ideale, deoarece permit evolu\u021bia f\u0103r\u0103 a provoca haos.<\/p>\nModific\u0103ri Breaking Change: Provoc\u0103ri Semnificative<\/h3>\n
\u0218i acum, partea dureroas\u0103. Schimb\u0103rile de tip “breaking change” sunt cele care modific\u0103 contractul API \u00eentr-un mod care invalideaz\u0103 clien\u021bii existen\u021bi. \u0218i crede\u021bi-m\u0103, am fost acolo. \u00cemi amintesc o situa\u021bie \u00een care un partener de logistic\u0103 a decis s\u0103 schimbe tipul de date al unui c\u00e2mp de la `integer` la `string` f\u0103r\u0103 niciun avertisment. Pentru ei, o modificare minor\u0103. Pentru noi? O cascad\u0103 de erori de serializare care a blocat procesarea comenzilor pentru trei ore. Trei ore de haos. Acestea sunt exact ce sunt modific\u0103rile breaking change la API<\/b>: schimb\u0103ri care rup contractul \u0219i for\u021beaz\u0103 clientul s\u0103-\u0219i modifice codul pentru a restabili func\u021bionalitatea. O adev\u0103rat\u0103 durere de cap. Eliminarea unui endpoint, redenumirea unui c\u00e2mp, schimbarea unui tip de date \u2013 toate sunt exemple clasice care provoac\u0103 modific\u0103ri API<\/b> disruptive.<\/p>\nDeprecierea API-urilor: Semnale de Avertizare \u0219i Planificare<\/h3>\n
Deprecierea este anun\u021bul politicos c\u0103 o anumit\u0103 parte a unui API (sau \u00eentregul API) urmeaz\u0103 s\u0103 fie eliminat\u0103 \u00een viitor. Este un semnal de avertizare. O practic\u0103 bun\u0103 implic\u0103 marcarea clar\u0103 a endpoint-urilor depreciate \u00een documenta\u021bie \u0219i, ideal, returnarea unui antet de avertizare \u00een r\u0103spunsurile API. Acest proces ofer\u0103 dezvoltatorilor o perioad\u0103 de gra\u021bie pentru a-\u0219i actualiza codul. O bun\u0103 gestionarea deprecierii API-urilor publice<\/b> este semnul unui furnizor matur \u0219i responsabil. Ignorarea acestor avertismente este o re\u021bet\u0103 sigur\u0103 pentru dezastru.<\/p>\nImpactul Modific\u0103rilor API Asupra Ecosistemului de Dezvoltare<\/h2>\n
Consecin\u021bele unor modific\u0103ri API<\/b> prost gestionate se propag\u0103 \u00een tot sistemul, afect\u00e2nd echipe, opera\u021biuni \u0219i, \u00een final, utilizatorii. Nu e doar o problem\u0103 tehnic\u0103.<\/p>\nCosturile Ascunse pentru Echipele de Dezvoltare<\/h3>\n
C\u00e2nd o modificare nea\u0219teptat\u0103 love\u0219te, timpul dezvoltatorilor este deviat de la crearea de noi func\u021bionalit\u0103\u021bi la stingerea incendiilor. Timpul petrecut pentru a investiga problema, a \u00een\u021belege noua documenta\u021bie (dac\u0103 exist\u0103!), a rescrie codul, a testa \u0219i a implementa corec\u021bia reprezint\u0103 costuri ascunse modific\u0103ri API dezvoltatori<\/b>. Ad\u0103uga\u021bi la asta frustrarea echipei \u0219i sc\u0103derea moralului. Nimeni nu vrea s\u0103-\u0219i petreac\u0103 ziua repar\u00e2nd integr\u0103ri din cauza lipsei de comunicare a altcuiva. Aceste modific\u0103ri API<\/b> pot afecta serios productivitatea.<\/p>\nRiscuri Opera\u021bionale \u0219i Timpi de Neutilizare<\/h3>\n
Impactul nu se opre\u0219te la echipa de dezvoltare. C\u00e2nd o integrare critic\u0103 e\u0219ueaz\u0103, poate duce la timpi de nefunc\u021bionare (downtime) pentru propria aplica\u021bie. Asta \u00eenseamn\u0103 pierderi de venituri, clien\u021bi nemul\u021bumi\u021bi \u0219i daune de imagine. Aceste riscuri asociate cu modific\u0103rile API neplanificate<\/b> sunt reale \u0219i pot fi devastatoare, mai ales pentru afacerile care se bazeaz\u0103 pe servicii ter\u021be pentru func\u021bionalit\u0103\u021bi cheie, cum ar fi procesarea pl\u0103\u021bilor sau logistica. Orice modific\u0103ri API<\/b> trebuie planificate.<\/p>\nExperien\u021ba Utilizatorului Final \u0219i Reputa\u021bia Brandului<\/h3>\n
Utilizatorul final nu \u0219tie \u0219i nici nu-i pas\u0103 de API-uri. El \u0219tie doar c\u0103 aplica\u021bia ta “nu merge”. Fie c\u0103 nu se poate autentifica, nu poate finaliza o achizi\u021bie sau nu prime\u0219te notific\u0103rile corecte, experien\u021ba sa este negativ\u0103. O serie de astfel de incidente erodeaz\u0103 \u00eencrederea \u0219i poate duce la pierderea clien\u021bilor. Reputa\u021bia unui brand, construit\u0103 cu greu, poate fi p\u0103tat\u0103 rapid de probleme tehnice recurente cauzate de modific\u0103ri API<\/b> prost gestionate. G\u00e2ndi\u021bi-v\u0103 la impactul modific\u0103rilor API asupra aplica\u021biilor legacy<\/b>, care sunt \u0219i mai greu de adaptat.<\/p>\nStrategii Eficiente pentru Gestionarea Modific\u0103rilor API<\/h2>\n
OK, am stabilit c\u0103 schimb\u0103rile sunt inevitabile \u0219i periculoase. Acum, ce facem? Din fericire, exist\u0103 strategii dovedite care ajut\u0103 la cum s\u0103 gestionezi modific\u0103rile API \u00een dezvoltare<\/b>.<\/p>\nVersionarea API-urilor: O Practic\u0103 Esen\u021bial\u0103<\/h3>\n
Versionarea este, probabil, cea mai important\u0103 strategie. \u00cen loc s\u0103 modifici API-ul existent, introduci o nou\u0103 versiune (de ex., \/v2\/). Acest lucru permite clien\u021bilor existen\u021bi s\u0103 continue s\u0103 foloseasc\u0103 versiunea veche, stabil\u0103 (v1), \u00een timp ce noii clien\u021bi sau cei gata de upgrade pot folosi v2. Este una dintre cele mai bune strategii de versionare API eficiente<\/b>. Versionarea poate fi implementat\u0103 \u00een URL (api.domeniu.com\/v2\/resursa), prin antete HTTP (Accept: application\/vnd.domeniu.v2+json) sau ca parametru de interogare. Aceast\u0103 abordare permite o tranzi\u021bie lin\u0103 \u0219i controlat\u0103 la noile modific\u0103ri API<\/b>. Un exemplu de politic\u0103 de versionare API<\/b> clar\u0103 este crucial.<\/p>\nComunicare Transparent\u0103 \u0219i Documenta\u021bie Clar\u0103<\/h3>\n
Comunicarea. Pare simplu, nu? \u0218i totu\u0219i, este punctul unde majoritatea e\u0219ueaz\u0103 lamentabil. O strategie de comunicare eficient\u0103 modific\u0103ri API parteneri<\/b> este vital\u0103. Public\u0103 un changelog detaliat. Trimite notific\u0103ri prin e-mail cu mult timp \u00eenainte de implementarea unor “breaking changes”. Men\u021bine o pagin\u0103 de status a serviciului. Documenta\u021bia trebuie s\u0103 fie mereu la zi, reflect\u00e2nd cu acurate\u021be starea actual\u0103 a API-ului. Aceste bune practici documentare modific\u0103ri API<\/b> sunt non-negociabile pentru a men\u021bine \u00eencrederea comunit\u0103\u021bii de dezvoltatori. Orice modific\u0103ri API<\/b> trebuie documentate.<\/p>\nPerioade de Gra\u021bie \u0219i Planuri de Migrare<\/h3>\n
C\u00e2nd introduci o modificare disruptiv\u0103 \u0219i depreciezi o versiune veche, nu po\u021bi pur \u0219i simplu s\u0103 tai accesul. Ofer\u0103 o perioad\u0103 de gra\u021bie rezonabil\u0103 (de la c\u00e2teva luni la un an, \u00een func\u021bie de complexitate) \u00een care ambele versiuni func\u021bioneaz\u0103 \u00een paralel. Furnizeaz\u0103 ghiduri clare de migrare care s\u0103 ajute dezvoltatorii s\u0103 fac\u0103 tranzi\u021bia. Acest proces de migrarea aplica\u021biilor la noi versiuni API<\/b> trebuie s\u0103 fie c\u00e2t mai simplu posibil. Abordarea arat\u0103 respect pentru timpul \u0219i efortul consumatorilor t\u0103i de API \u0219i minimizeaz\u0103 impactul negativ al acestor modific\u0103ri API<\/b>.<\/p>\nBune Practici pentru Designul API Orientat spre Stabilitate \u0219i Evolu\u021bie<\/h2>\n
Gestionarea schimb\u0103rilor \u00eencepe \u00eenc\u0103 din faza de proiectare. Construirea unui API cu g\u00e2ndul la viitor poate preveni multe dureri de cap.<\/p>\n
Proiecteaz\u0103 pentru flexibilitate. Folose\u0219te formate de date extensibile precum JSON. Evit\u0103 structurile rigide. G\u00e2nde\u0219te-te la viitoarele cazuri de utilizare. Un design bun nu \u00eencearc\u0103 s\u0103 prevad\u0103 totul, ci s\u0103 permit\u0103 ad\u0103ugarea de noi elemente f\u0103r\u0103 a le strica pe cele vechi. Implementarea unor arhitecturi API reziliente la modific\u0103ri<\/b> este cheia succesului pe termen lung \u0219i reduce impactul unor viitoare modific\u0103ri API<\/b>.<\/p>\nImportan\u021ba Test\u0103rii \u0219i Valid\u0103rii Continue<\/h3>\n
Testarea este plasa ta de siguran\u021b\u0103. Implementeaz\u0103 un set solid de teste automate: teste unitare, de integrare \u0219i, cel mai important, teste de contract. Testarea contractului valideaz\u0103 c\u0103 API-ul respect\u0103 specifica\u021biile definite, asigur\u00e2ndu-se c\u0103 nu introduci accidental modific\u0103ri API<\/b> disruptive. O bun\u0103 practic\u0103 este testarea compatibilit\u0103\u021bii dup\u0103 modific\u0103ri API<\/b>, folosind pipeline-uri CI\/CD pentru a rula aceste verific\u0103ri la fiecare modificare de cod. F\u0103r\u0103 testare, zbori pe nev\u0103zute.<\/p>\nColectarea Feedback-ului Comunit\u0103\u021bii de Dezvoltatori<\/h3>\n
Dezvoltatorii care \u00ee\u021bi folosesc API-ul sunt cea mai valoroas\u0103 resurs\u0103 de feedback. Creeaz\u0103 canale de comunicare deschise: un forum, un tracker de probleme, un canal de Slack. Ascult\u0103-le frustr\u0103rile \u0219i sugestiile. Adesea, ei vor identifica probleme \u0219i vor sugera \u00eembun\u0103t\u0103\u021biri la care nu te-ai fi g\u00e2ndit. Implicarea comunit\u0103\u021bii \u00een procesul de evolu\u021bie a API-ului poate transforma poten\u021biale modific\u0103ri API<\/b> problematice \u00een oportunit\u0103\u021bi de colaborare \u0219i \u00eembun\u0103t\u0103\u021bire.<\/p>\nInstrumente \u0219i Tehnologii pentru Monitorizarea \u0219i Adaptarea la Modific\u0103rile API<\/h2>\n
Din fericire, nu trebuie s\u0103 faci totul manual. Exist\u0103 o multitudine de unelte care te pot ajuta s\u0103 navighezi \u00een acest peisaj complex.<\/p>\n
Un API Gateway ac\u021bioneaz\u0103 ca un intermediar \u00eentre client \u0219i serviciile tale de backend. Poate juca un rol crucial \u00een gestionarea schimb\u0103rilor. De exemplu, un gateway poate ruta traficul c\u0103tre diferite versiuni ale unui serviciu, poate transforma cereri \u0219i r\u0103spunsuri pentru a men\u021bine compatibilitatea sau poate implementa politici de securitate \u0219i limitare a ratei. Este un instrument puternic pentru a gestiona modific\u0103ri API<\/b> f\u0103r\u0103 a modifica codul de baz\u0103.<\/p>\nPlatforme de Management API \u0219i Automatizare<\/h3>\n
Platforme complete de management API, cum ar fi Postman, SwaggerHub sau Apigee, ofer\u0103 solu\u021bii integrate pentru proiectare, testare, documentare, monitorizare \u0219i publicare. Aceste instrumente pentru monitorizarea schimb\u0103rilor API<\/b> pot automatiza o mare parte din proces, de la generarea documenta\u021biei la configurarea monitoarelor care verific\u0103 disponibilitatea \u0219i corectitudinea endpoint-urilor. Acestea ajut\u0103 la optimizarea procesului de adaptare la modific\u0103ri API<\/b>.<\/p>\nSolu\u021bii pentru Testare Automat\u0103 \u0219i Monitorizare Continu\u0103<\/h3>\n
Integrarea test\u0103rii automate \u00een pipeline-ul de livrare continu\u0103 (CI\/CD) este esen\u021bial\u0103. Instrumente precum Jenkins, GitLab CI sau GitHub Actions pot rula automat seturi de teste la fiecare commit, prinz\u00e2nd regresiile \u00eenainte ca acestea s\u0103 ajung\u0103 \u00een produc\u021bie. Monitorizarea continu\u0103 cu unelte ca Datadog, New Relic sau Prometheus te alerteaz\u0103 \u00een timp real despre erori sau degrad\u0103ri de performan\u021b\u0103, permi\u021b\u00e2ndu-\u021bi s\u0103 reac\u021bionezi rapid la problemele cauzate de modific\u0103ri API<\/b>, ajut\u00e2nd la minimizarea impactului. Aceste solu\u021bii pentru a minimiza impactul modific\u0103rilor API<\/b> sunt critice.<\/p>\nConcluzie: Navigarea cu Succes \u00een Peisajul Dinamic al API-urilor<\/h2>\n
Gestionarea eficient\u0103 a schimb\u0103rilor nu este o op\u021biune, ci o necesitate. Orice modific\u0103ri API<\/b> poart\u0103 cu ele at\u00e2t riscuri, c\u00e2t \u0219i oportunit\u0103\u021bi. Cheia este s\u0103 abordezi acest proces cu o strategie clar\u0103, bazat\u0103 pe comunicare, planificare \u0219i instrumente adecvate.<\/p>\nConstruirea unei Culturi de Adaptare<\/h3>\n
Mai presus de orice tehnologie sau proces, succesul depinde de cultur\u0103. O echip\u0103 care \u00een\u021belege c\u0103 schimbarea este normal\u0103 \u0219i care este preg\u0103tit\u0103 s\u0103 se adapteze va avea \u00eentotdeauna un avantaj. Aceasta implic\u0103 o mentalitate proactiv\u0103, nu reactiv\u0103, \u0219i recunoa\u0219terea beneficiilor pe care le aduce managementului proactiv al modific\u0103rilor API<\/b>. Acceptarea acestor modific\u0103ri API<\/b> este un pas \u00eenainte. Vedem zilnic provoc\u0103rile implement\u0103rii modific\u0103rilor API<\/b>.<\/p>\nViitorul Modific\u0103rilor API \u0219i Inova\u021bia<\/h3>\n
Lumea API-urilor continu\u0103 s\u0103 evolueze. Tehnologii precum GraphQL promit s\u0103 reduc\u0103 nevoia de versionare tradi\u021bional\u0103, permi\u021b\u00e2nd clien\u021bilor s\u0103 cear\u0103 exact datele de care au nevoie. Cu toate acestea, principiile fundamentale r\u0103m\u00e2n acelea\u0219i: comunic\u0103 transparent, planific\u0103 atent \u0219i proiecteaz\u0103 pentru rezilien\u021b\u0103. \u00cen final, capacitatea de a gestiona aceste modific\u0103ri API<\/b> nu este doar o abilitate tehnic\u0103, ci un motor pentru inova\u021bie continu\u0103. \u00centr-o lume digital\u0103 \u00een permanent\u0103 mi\u0219care, cei care st\u0103p\u00e2nesc arta schimb\u0103rii sunt cei care vor construi viitorul. Modific\u0103rile nu se vor opri. Nici noi nu ar trebui. Cum afecteaz\u0103 modific\u0103rile API<\/b> performan\u021ba sistemelor? R\u0103m\u00e2ne o \u00eentrebare central\u0103 pentru viitor.<\/p>\n","protected":false},"excerpt":{"rendered":"
Este mar\u021bi diminea\u021ba. Cafeaua abia \u0219i-a f\u0103cut efectul, iar tu deschizi laptopul, gata de o nou\u0103 zi productiv\u0103. Dar ceva e \u00een neregul\u0103. Alertele se aprind ca un brad de Cr\u0103ciun \u00een iulie. Serviciul X, de care depinde jum\u0103tate din aplica\u021bia ta, a picat. Sau, mai r\u0103u, r\u0103spunde cu erori pe care nu le-ai mai […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-410","post","type-post","status-publish","format-standard","hentry","category-tehnologie"],"_links":{"self":[{"href":"https:\/\/worldpoint.eu\/ro\/wp-json\/wp\/v2\/posts\/410","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/worldpoint.eu\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/worldpoint.eu\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/worldpoint.eu\/ro\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/worldpoint.eu\/ro\/wp-json\/wp\/v2\/comments?post=410"}],"version-history":[{"count":0,"href":"https:\/\/worldpoint.eu\/ro\/wp-json\/wp\/v2\/posts\/410\/revisions"}],"wp:attachment":[{"href":"https:\/\/worldpoint.eu\/ro\/wp-json\/wp\/v2\/media?parent=410"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/worldpoint.eu\/ro\/wp-json\/wp\/v2\/categories?post=410"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/worldpoint.eu\/ro\/wp-json\/wp\/v2\/tags?post=410"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}