{"id":52584,"date":"2019-11-12T00:00:00","date_gmt":"2019-11-11T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/zamena-eav-na-jsonb-v-postgresql"},"modified":"2020-02-18T14:00:21","modified_gmt":"2020-02-18T11:00:21","slug":"zamena-eav-na-jsonb-v-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/zamena-eav-na-jsonb-v-postgresql","title":{"rendered":"Sostituzione di EAV con JSONB in PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

TL; DR: JSONB pu\u00f2 semplificare notevolmente lo sviluppo dello schema del database senza compromettere le prestazioni delle query.<\/p><\/blockquote>\n

<\/p>\n

Introduzione<\/h3>\n

\nFacciamo un esempio classico, probabilmente uno dei pi\u00f9 antichi casi d'uso nel mondo dei database relazionali: abbiamo un'entit\u00e0 e dobbiamo memorizzare alcune propriet\u00e0 (attributi) di questa entit\u00e0. Tuttavia, non tutti gli oggetti possono avere lo stesso insieme di propriet\u00e0 e, inoltre, in futuro potrebbe essere necessario aggiungere ulteriori propriet\u00e0.<\/p>\n

Il modo pi\u00f9 semplice per risolvere questo problema \u00e8 creare una colonna nella tabella del database per ogni valore di propriet\u00e0 e semplicemente compilare quelle necessarie per un determinato oggetto. Ottimo! Problema risolto... fino a quando la vostra tabella non contiene milioni di record e non avete bisogno di aggiungere una nuova registrazione.<\/p>\n

Consideriamo il pattern EAV (Entity-Attribute-Value<\/a><\/noindex>), che si incontra abbastanza spesso. Una tabella contiene entit\u00e0 (record), un'altra tabella contiene i nomi delle propriet\u00e0 (attributi), e una terza tabella collega le entit\u00e0 ai loro attributi e contiene il valore di questi attributi per l'entit\u00e0 attuale. Questo ti consente di avere set di propriet\u00e0 diversi per oggetti differenti e di aggiungere propriet\u00e0 \"al volo\", senza modificare la struttura del database.
\n<\/a><\/noindex>
\nTuttavia, non scriverei questa nota se non ci fossero difetti nell'approccio che utilizza EVA. Ad esempio, per ottenere una o pi\u00f9 entit\u00e0 che hanno 1 attributo, sono necessari 2 join nella query: il primo \u00e8 un'unione con la tabella degli attributi, il secondo \u00e8 un'unione con la tabella dei valori. Se l'entit\u00e0 ha 2 attributi, servono gi\u00e0 4 join! Inoltre, tutti gli attributi sono solitamente memorizzati come stringhe, il che comporta conversioni di tipo, sia per i risultati che per la condizione WHERE. Se si scrivono molte query, questo \u00e8 abbastanza dispendioso in termini di utilizzo delle risorse.<\/p>\n

Nonostante questi evidenti svantaggi, l'EAV \u00e8 gi\u00e0 da tempo utilizzato per affrontare questo tipo di problemi. Questi erano difetti inevitabili e non c'era semplicemente una migliore alternativa.
\nMa poi in PostgreSQL \u00e8 emersa una nuova \"tecnologia\"...<\/p>\n

A partire da PostgreSQL 9.4, \u00e8 stato aggiunto il tipo di dato JSONB per conservare dati JSON binari. Sebbene la memorizzazione dei JSON in questo formato richieda solitamente un po' pi\u00f9 di spazio e tempo rispetto al JSON in formato testo semplice, l'esecuzione delle operazioni su di esso avviene molto pi\u00f9 rapidamente. Inoltre, JSONB supporta l'indicizzazione, il che rende le query su di esso ancora pi\u00f9 veloci.<\/p>\n

Il tipo di dato JSONB ci consente di sostituire il pesante schema EAV semplicemente aggiungendo una sola colonna JSONB alla nostra tabella delle entit\u00e0, semplificando notevolmente il design del database. Tuttavia, molti sostengono che ci\u00f2 debba comportare una riduzione delle prestazioni\u2026 \u00c8 per questo motivo che \u00e8 nato questo articolo.<\/p>\n

Impostazione del database di test<\/h3>\n

\nPer questo confronto ho creato un database su una nuova installazione di PostgreSQL 9.5 su un'installazione da 80 dollari DigitalOcean<\/a><\/noindex> Ubuntu 14.04. Dopo aver configurato alcuni parametri in postgresql.conf, ho eseguito questo<\/a><\/noindex> uno script utilizzando psql. Per rappresentare i dati in formato EAV sono state create le seguenti tabelle:<\/p>\n

CREATE TABLE entity ( \n  id           SERIAL PRIMARY KEY, \n  name         TEXT, \n  description  TEXT\n);\nCREATE TABLE entity_attribute (\n  id          SERIAL PRIMARY KEY, \n  name        TEXT\n);\nCREATE TABLE entity_attribute_value (\n  id                  SERIAL PRIMARY KEY, \n  entity_id           INT    REFERENCES entity(id), \n  entity_attribute_id INT    REFERENCES entity_attribute(id), \n  value               TEXT\n);\n<\/code><\/pre>\n
\nDi seguito \u00e8 riportata una tabella in cui verranno memorizzati gli stessi dati, ma con gli attributi in una colonna di tipo JSONB \u2013 properties<\/i>.<\/p>\n
CREATE TABLE entity_jsonb (\n  id          SERIAL PRIMARY KEY, \n  name        TEXT, \n  description TEXT,\n  properties  JSONB\n);\n<\/code><\/pre>\n
\nSembra molto pi\u00f9 semplice, non \u00e8 vero? Poi sono state aggiunte alle tabelle delle entit\u00e0 (entity<\/i> & entity_jsonb<\/i>) 10 milioni di record, e di conseguenza, sono stati riempiti con gli stessi dati le tabelle dove si utilizza lo schema EAV e l'approccio con la colonna JSONB \u2013 entity_jsonb.properties<\/i>. Cos\u00ec abbiamo ottenuto diversi tipi di dati tra l'insieme di propriet\u00e0. Esempio di dati:<\/p>\n
{\n  id:          1\n  name:        \"Entity1\"\n  description: \"Entit\u00e0 di test n. 1\"\n  properties:  {\n    color:        \"rosso\"\n    lenght:       120\n    width:        3.1882420\n    hassomething: true\n    country:      \"Belgio\"\n  } \n}<\/code><\/pre>\n
\nQuindi ora abbiamo dati identici per le due varianti. Iniziamo a confrontare le implementazioni in azione!<\/p>\n
Semplificazione del design<\/h3>\n
\n\u00c8 stato gi\u00e0 detto in precedenza che il design del database \u00e8 stato notevolmente semplificato: una tabella, grazie all'uso della colonna JSONB per le propriet\u00e0, invece di utilizzare tre tabelle per EAV. Ma come si riflette questo nelle query? L'aggiornamento di una propriet\u00e0 dell'entit\u00e0 si presenta come segue:<\/p>\n
-- EAV\nUPDATE entity_attribute_value \nSET value = 'blu' \nWHERE entity_attribute_id = 1 \n  AND entity_id = 120;\n\n-- JSONB\nUPDATE entity_jsonb \nSET properties = jsonb_set(properties, '{\"color\"}', '\"blu\"') \nWHERE id = 120;\n<\/code><\/pre>\n
\nCome vediamo, l'ultima query non sembra pi\u00f9 semplice. Per aggiornare il valore di una propriet\u00e0 in un oggetto JSONB, dobbiamo utilizzare la funzione jsonb_set()<\/a><\/noindex>, e dobbiamo passare il nostro nuovo valore come oggetto JSONB. Tuttavia, non dobbiamo conoscere alcun identificatore in anticipo. Guardando l'esempio con EAV, dobbiamo conoscere sia l'entity_id che l'entity_attribute_id per eseguire l'aggiornamento. Se vuoi aggiornare una propriet\u00e0 nella colonna JSONB basandoti sul nome dell'oggetto, tutto questo si fa in una semplice riga.<\/p>\n
Ora scegliamo l'entit\u00e0 che abbiamo appena aggiornato, in base al suo nuovo colore:<\/p>\n
-- EAV\nSELECT e.name \nFROM entity e \n  INNER JOIN entity_attribute_value eav ON e.id = eav.entity_id\n  INNER JOIN entity_attribute ea ON eav.entity_attribute_id = ea.id\nWHERE ea.name = 'color' AND eav.value = 'blu';\n\n-- JSONB\nSELECT name \nFROM entity_jsonb \nWHERE properties ->> 'color' = 'blu';\n<\/code><\/pre>\n
\nCredo che possiamo concordare sul fatto che il secondo \u00e8 pi\u00f9 corto (senza join!), e quindi pi\u00f9 leggibile. Qui vince JSONB! Utilizziamo l'operatore JSON ->> per ottenere il colore come valore di testo dall'oggetto JSONB. Esiste anche un secondo modo per ottenere lo stesso risultato nel modello JSONB utilizzando l'operatore @>:<\/p>\n
-- JSONB \nSELECT name \nFROM entity_jsonb \nWHERE properties @> '{\"color\": \"blu\"}';\n<\/code><\/pre>\n
\nQuesto \u00e8 un po' pi\u00f9 complicato: stiamo verificando se l'oggetto JSON nella colonna delle propriet\u00e0 contiene l'oggetto che si trova a destra dell'operatore @>. Meno leggibile, pi\u00f9 performante (vedi oltre). <\/p>\n
Semplifichiamo ulteriormente l'uso di JSONB quando hai bisogno di selezionare pi\u00f9 propriet\u00e0 contemporaneamente. Qui \u00e8 dove il metodo JSONB si adatta veramente: semplicemente selezioniamo le propriet\u00e0 come colonne aggiuntive nel nostro set di risultati senza necessit\u00e0 di join:<\/p>\n
-- JSONB \nSELECT name\n  , properties ->> 'color'\n  , properties ->> 'country'\nFROM entity_jsonb \nWHERE id = 120;\n<\/code><\/pre>\n
\nCon EAV avrai bisogno di 2 join per ogni propriet\u00e0 che desideri interrogare. A mio parere, le query sopra mostrano un grande semplificazione nel design del database. \u00c8 possibile vedere ulteriori esempi su come scrivere query in JSONB anche nel seguente<\/a><\/noindex> post.
\nOra \u00e8 il momento di parlare delle prestazioni.<\/p>\n
Prestazioni<\/h3>\n
\nPer confrontare le prestazioni, ho utilizzato EXPLAIN ANALYZE<\/a><\/noindex> nelle query, per misurare il tempo di esecuzione. Ogni query \u00e8 stata eseguita almeno tre volte, poich\u00e9 la prima volta il pianificatore delle query richiede pi\u00f9 tempo. Inizialmente ho eseguito le query senza alcun indice. Ovviamente, ci\u00f2 ha avvantaggiato JSONB, poich\u00e9 i join necessari per EAV non potevano utilizzare indici (i campi delle chiavi esterne non erano indicizzati). Dopo, ho creato un indice per due colonne delle chiavi esterne nella tabella dei valori EAV, oltre a un indice GIN<\/a><\/noindex> per la colonna JSONB.<\/p>\n
Gli aggiornamenti dei dati hanno mostrato i seguenti risultati sui tempi (in ms). Si prega di notare che la scala \u00e8 logaritmica:<\/p>\n
\"Sostituzione
\n
\nSi osserva che JSONB \u00e8 molto pi\u00f9 (> 50000 volte) veloce di EAV se non si utilizzano indici, a causa del motivo sopra indicato. Quando indicizziamo le colonne con le chiavi primarie, la differenza quasi scompare, ma JSONB \u00e8 ancora 1,3 volte pi\u00f9 veloce di EAV. Si noti che l'indice nella colonna JSONB qui non ha alcun impatto, poich\u00e9 non utilizziamo la colonna delle propriet\u00e0 nei criteri di valutazione. <\/p>\n
Per la selezione dei dati in base al valore della propriet\u00e0 otteniamo i seguenti risultati (scala normale):<\/p>\n
\"Sostituzione
\n
\nSi pu\u00f2 notare che JSONB funziona di nuovo pi\u00f9 velocemente di EAV senza indici, ma quando EAV ha indici \u2013 comunque risulta pi\u00f9 veloce di JSONB. Tuttavia, ho notato che il tempo per le query JSONB era lo stesso, il che mi ha portato a pensare che l'indice GIN non si attivasse. Presumibilmente, quando si utilizza un indice GIN per una colonna con propriet\u00e0 popolate, questo funziona solo quando si usa l'operatore di inclusione @>. Ho utilizzato questo in un nuovo test, il che ha avuto un enorme impatto sul tempo: solo 0,153 ms! Questo \u00e8 15000 volte pi\u00f9 veloce di EAV e 25000 volte pi\u00f9 veloce dell'operatore ->>. <\/p>\n
Penso che sia stato abbastanza veloce!<\/p>\n
Dimensione delle tabelle del database<\/h3>\n
\nConfrontiamo le dimensioni delle tabelle con entrambi gli approcci. In psql possiamo mostrari la dimensione di tutte le tabelle e degli indici con il comando dti+<\/b><\/p>\n
\"Sostituzione
\n
\nPer l'approccio EAV, le dimensioni delle tabelle ammontano a circa 3068 MB, e gli indici fino a 3427 MB, il che in totale equivale a 6,43 GB. Utilizzando l'approccio con JSONB si utilizzano 1817 MB per la tabella e 318 MB per gli indici, per un totale di 2,08 GB. Risultando in tre volte di meno! Questo fatto mi ha sorpreso un po', poich\u00e9 memorizziamo i nomi delle propriet\u00e0 in ogni oggetto JSONB. <\/p>\n
Tuttavia, i numeri parlano chiaro: in EAV conserviamo 2 chiavi esterne intere per il valore dell'attributo, il che si traduce in 8 byte di dati aggiuntivi. Inoltre, in EAV tutti i valori delle propriet\u00e0 sono memorizzati come testo, mentre JSONB utilizza valori numerici e booleani dove possibile, risultando in una dimensione complessiva inferiore.<\/p>\n
Conclusioni<\/h3>\n
\nIn generale, penso che conservare le propriet\u00e0 delle entit\u00e0 nel formato JSONB possa semplificare notevolmente la progettazione e la manutenzione del vostro database. Se eseguite molte query, tutto ci\u00f2 che \u00e8 memorizzato in una sola tabella con l'entit\u00e0 funzioner\u00e0 davvero in modo pi\u00f9 efficiente. Il fatto che ci\u00f2 semplifichi l'interazione tra i dati \u00e8 gi\u00e0 un vantaggio, ma anche il database risultante \u00e8 tre volte pi\u00f9 piccolo in dimensione.<\/p>\n
Inoltre, dai test svolti, si pu\u00f2 concludere che le perdite di performance sono molto trascurabili. In alcuni casi, JSONB funziona anche pi\u00f9 velocemente rispetto a EAV, il che lo rende ancora migliore. Tuttavia, questo test di riferimento ovviamente non copre tutti gli aspetti (ad esempio, entit\u00e0 con un numero molto elevato di propriet\u00e0, un significativo aumento delle propriet\u00e0 dei dati esistenti, ecc.), quindi, se avete suggerimenti su come migliorarlo, non esitate a lasciarli nei commenti!
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
TL; DR: JSONB \u043c\u043e\u0436\u0435\u0442 \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0443\u043f\u0440\u043e\u0441\u0442\u0438\u0442\u044c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0443 \u0441\u0445\u0435\u043c\u044b \u0411\u0414 \u0431\u0435\u0437 \u0443\u0449\u0435\u0440\u0431\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432 \u0437\u0430\u043f\u0440\u043e\u0441\u0430\u0445. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041f\u0440\u0438\u0432\u0435\u0434\u0435\u043c \u043a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043f\u0440\u0438\u043c\u0435\u0440, \u043d\u0430\u0432\u0435\u0440\u043d\u043e\u0435, \u043e\u0434\u043d\u043e\u0433\u043e \u0438\u0437 \u0441\u0442\u0430\u0440\u0435\u0439\u0448\u0438\u0445 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u043e\u0432 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u0432 \u043c\u0438\u0440\u0435 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0411\u0414 (\u0431\u0430\u0437\u0430 \u0434\u0430\u043d\u043d\u044b\u0445): \u0443 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0441\u0443\u0449\u043d\u043e\u0441\u0442\u044c, \u0438 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u0441\u043e\u0445\u0440\u0430\u043d\u0438\u0442\u044c \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0435 \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u0430 (\u0430\u0442\u0440\u0438\u0431\u0443\u0442\u044b) \u044d\u0442\u043e\u0439 \u0441\u0443\u0449\u043d\u043e\u0441\u0442\u0438. \u041d\u043e \u043d\u0435 \u0432\u0441\u0435 \u044d\u043a\u0437\u0435\u043c\u043f\u043b\u044f\u0440\u044b \u043c\u043e\u0433\u0443\u0442 \u0438\u043c\u0435\u044e\u0442 \u043e\u0434\u0438\u043d\u0430\u043a\u043e\u0432\u044b\u0439 \u043d\u0430\u0431\u043e\u0440 \u0441\u0432\u043e\u0439\u0441\u0442\u0432, \u043a \u0442\u043e\u043c\u0443 \u0436\u0435 \u0432 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52584","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Sostituzione di EAV con JSONB in PostgreSQL | ProHoster","description":"TL; DR: JSONB pu\u00f2 semplificare notevolmente lo sviluppo di uno schema di database senza compromettere le performance delle query. Introduzione Presentiamo un esempio classico, probabilmente uno dei pi\u00f9 antichi.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/zamena-eav-na-jsonb-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u0430\u043c\u0435\u043d\u0430 EAV \u043d\u0430 JSONB \u0432 PostgreSQL | ProHoster","og:description":"TL; DR: JSONB \u043c\u043e\u0436\u0435\u0442 \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0443\u043f\u0440\u043e\u0441\u0442\u0438\u0442\u044c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0443 \u0441\u0445\u0435\u043c\u044b \u0411\u0414 \u0431\u0435\u0437 \u0443\u0449\u0435\u0440\u0431\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432 \u0437\u0430\u043f\u0440\u043e\u0441\u0430\u0445. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041f\u0440\u0438\u0432\u0435\u0434\u0435\u043c \u043a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043f\u0440\u0438\u043c\u0435\u0440, \u043d\u0430\u0432\u0435\u0440\u043d\u043e\u0435, \u043e\u0434\u043d\u043e\u0433\u043e \u0438\u0437 \u0441\u0442\u0430\u0440\u0435\u0439\u0448\u0438\u0445.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/zamena-eav-na-jsonb-v-postgresql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-11T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:21+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52584","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 04:07:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:40:27","updated":"2026-01-24 04:07:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/52584","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=52584"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/52584\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=52584"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=52584"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=52584"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}