{"id":31385,"date":"2019-10-31T21:40:58","date_gmt":"2019-10-31T18:40:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/biznes-logika-v-baze-dannyh-pri-pomoshhi-schemakeeper\/"},"modified":"2019-10-31T21:40:58","modified_gmt":"2019-10-31T18:40:58","slug":"biznes-logika-v-baze-dannyh-pri-pomoshhi-schemakeeper","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/biznes-logika-v-baze-dannyh-pri-pomoshhi-schemakeeper","title":{"rendered":"Logica aziendale nel database tramite SchemaKeeper","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

L'obiettivo di questo articolo \u00e8 illustrare, attraverso la libreria schema-keeper<\/a><\/noindex> , gli strumenti che consentono di semplificare notevolmente il processo di sviluppo di database all'interno di progetti PHP che utilizzano il DBMS PostgreSQL.<\/p>\n

<\/p>\n

Le informazioni di questo articolo saranno utili in primo luogo agli sviluppatori che desiderano sfruttare al massimo le potenzialit\u00e0 di PostgreSQL, ma che si trovano ad affrontare problemi di manutenzione della logica aziendale spostata nel database. <\/p>\n

<\/p>\n

L'articolo non descriver\u00e0 i vantaggi o gli svantaggi di conservare la logica aziendale nel database. Si presume che la scelta sia gi\u00e0 stata fatta dal lettore.<\/p>\n

<\/p>\n

Saranno esaminati i seguenti punti:<\/p>\n

<\/p>\n

    \n
  1. In quale formato conservare il dump della struttura del database nel sistema di controllo versione (di seguito VCS)<\/li>\n
  2. Come monitorare le modifiche alla struttura del database dopo aver salvato il dump<\/li>\n
  3. Come trasferire le modifiche alla struttura del database in altri ambienti senza conflitti e senza giganteschi file di migrazione<\/li>\n
  4. Come organizzare il lavoro parallelo su un progetto da parte di pi\u00f9 sviluppatori<\/li>\n
  5. Come implementare in modo sicuro un numero maggiore di modifiche alla struttura del database nell'ambiente di produzione<\/a><\/noindex>
    \n

    SchemaKeeper<\/strong> \u00e8 progettato per lavorare con procedure memorizzate scritte nel linguaggio PL\/pgSQL<\/a><\/noindex>. I test con altri linguaggi non sono stati effettuati, pertanto l'uso potrebbe non essere altrettanto efficace o potrebbe essere impossibile.\n<\/p><\/blockquote>\n<\/li>\n<\/ol>\n

    <\/p>\n

    In quale formato conservare il dump della struttura del database nel VCS<\/h2>\n

    <\/p>\n

    La libreria schema-keeper<\/a><\/noindex> fornisce la funzione saveDump<\/code>, che salva la struttura di tutti gli oggetti dal database come singoli file di testo. In output viene creata una directory contenente la struttura del database, suddivisa in file raggruppati, che possono essere facilmente aggiunti al VCS.<\/p>\n

    <\/p>\n

    Esaminiamo la trasformazione degli oggetti dal database in file con alcuni esempi:<\/p>\n

    <\/p>\n

    Tipo di oggetto
    \nSchema
    \nNome
    \nPercorso relativo al file<\/p>\n

    Tabella
    \npubblico
    \naccounts
    \n.\/public\/tables\/accounts.txt<\/code><\/p>\n

    Procedura memorizzata
    \npubblico
    \nauth(hash bigint)
    \n.\/public\/functions\/auth(int8).sql<\/code><\/p>\n

    Rappresentazione
    \nbooking
    \ntariffs
    \n.\/booking\/views\/tariffs.txt<\/code><\/p>\n

    <\/p>\n

    Il contenuto dei file \u00e8 una rappresentazione testuale della struttura di un particolare oggetto del database. Ad esempio, per le procedure memorizzate, il contenuto del file sar\u00e0 la definizione completa della procedura memorizzata, che inizia con il blocco CREATE OR REPLACE FUNCTION<\/code>.<\/p>\n

    <\/p>\n

    Come si pu\u00f2 vedere dalla tabella sopra, il percorso del file contiene informazioni sul tipo, sullo schema e sul nome dell'oggetto. Questo approccio facilita la navigazione nel dump e la revisione del codice delle modifiche nel database.<\/p>\n

    <\/p>\n

    Estensione .sql<\/code> per i file con codice sorgente delle procedure memorizzate, \u00e8 stato scelto affinch\u00e9 l'IDE fornisca automaticamente gli strumenti per interagire con il database all'apertura del file.<\/p><\/blockquote>\n

    <\/p>\n

    Come monitorare le modifiche alla struttura del database dopo aver salvato il dump<\/h2>\n

    <\/p>\n

    Salvando il dump della struttura attuale del database in VCS, otteniamo la possibilit\u00e0 di verificare se sono state apportate modifiche alla struttura del database dopo la creazione del dump. Nella libreria schema-keeper<\/a><\/noindex> \u00e8 prevista una funzione per rilevare le modifiche nella struttura del database verifyDump<\/code>, che restituisce informazioni sulle differenze senza effetti collaterali. <\/p>\n

    <\/p>\n

    Un modo alternativo per controllare \u00e8 richiamare nuovamente la funzione saveDump<\/code>, specificando la stessa directory, e controllare in VCS la presenza di modifiche. Poich\u00e9 tutti gli oggetti del database sono salvati in file separati, VCS mostrer\u00e0 solo gli oggetti modificati.
    \nIl principale svantaggio di questo metodo \u00e8 la necessit\u00e0 di sovrascrivere i file per visualizzare le modifiche.<\/p>\n

    <\/p>\n

    Come trasferire le modifiche alla struttura del database in altri ambienti senza conflitti e senza giganteschi file di migrazione<\/h2>\n

    <\/p>\n

    Grazie alla funzione deployDump<\/code> , il codice sorgente delle procedure memorizzate pu\u00f2 essere modificato esattamente come il codice sorgente dell'applicazione. \u00c8 possibile aggiungere\/rimuovere nuove righe nel codice delle procedure memorizzate e inviare immediatamente le modifiche nel sistema di controllo versione, oppure creare\/rimuovere procedure memorizzate creando\/rimuovendo i corrispondenti file nella directory del dump. <\/p>\n

    <\/p>\n

    Ad esempio, per creare una nuova procedura memorizzata nello schema pubblico<\/code> , \u00e8 sufficiente creare un nuovo file con estensione .sql<\/code> nella directory public\/functions<\/code>, inserire il codice sorgente della procedura memorizzata, incluso il blocco CREATE OR REPLACE FUNCTION<\/code>, e poi richiamare la funzione deployDump<\/code>. Allo stesso modo avviene la modifica e la rimozione della procedura memorizzata. In questo modo, il codice entra sia in VCS che nel database. <\/p>\n

    <\/p>\n

    Se nel codice sorgente di una qualsiasi procedura memorizzata si verifica un errore, oppure un'incongruenza tra il nome del file e la procedura memorizzata, allora deployDump<\/code> non verr\u00e0 eseguita, mostrando il testo dell'errore. La discordanza delle procedure memorizzate tra il dump e il database attuale \u00e8 impossibile utilizzando deployDump<\/code>.<\/p>\n

    <\/p>\n

    Quando si crea una nuova procedura memorizzata, non \u00e8 necessario immettere manualmente il nome corretto del file. \u00c8 sufficiente che il file abbia l'estensione .sql<\/code>. Dopo la chiamata, deployDump<\/code> il testo dell'errore conterr\u00e0 il nome corretto che pu\u00f2 essere utilizzato per rinominare il file.<\/p><\/blockquote>\n

    deployDump<\/code> permette di modificare i parametri della funzione o il tipo di ritorno senza ulteriori azioni, mentre nell'approccio classico sarebbe stato necessario
    \neseguire prima DROP FUNCTION<\/code>, e solo dopo CREATE OR REPLACE FUNCTION<\/code>.<\/p>\n

    <\/p>\n

    Purtroppo, ci sono alcune situazioni in cui deployDump<\/code> non \u00e8 possibile applicare automaticamente le modifiche. Ad esempio, se viene rimossa una funzione di trigger utilizzata da almeno un trigger. Queste situazioni devono essere gestite manualmente utilizzando i file di migrazione.<\/p>\n

    <\/p>\n

    Se il trasferimento delle modifiche nelle procedure memorizzate \u00e8 responsabilit\u00e0 dello schema-keeper<\/a><\/noindex>, per trasferire le altre modifiche nella struttura \u00e8 necessario utilizzare i file di migrazione. Ad esempio, una buona libreria per lavorare con le migrazioni \u00e8 doctrine\/migrations<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Le migrazioni devono essere applicate prima dell'avvio deployDump<\/code>. Questo consente di apportare tutte le modifiche alla struttura e risolvere le situazioni problematiche, affinch\u00e9 le modifiche nelle procedure memorizzate possano successivamente essere trasferite senza problemi.<\/p>\n

    <\/p>\n

    Un'analisi pi\u00f9 dettagliata del lavoro con le migrazioni sar\u00e0 fornita nei capitoli successivi.<\/p>\n

    <\/p>\n

    Come organizzare il lavoro parallelo su un progetto da parte di pi\u00f9 sviluppatori<\/h2>\n

    <\/p>\n

    \u00c8 necessario creare uno script per l'inizializzazione completa del database, che sar\u00e0 eseguito dallo sviluppatore sulla propria macchina di lavoro, allineando la struttura del database locale a quella salvata nel dump VCS. La cosa pi\u00f9 semplice \u00e8 suddividere l'inizializzazione del database locale in 3 passaggi:<\/p>\n

    <\/p>\n

      \n
    1. Importazione di un file con la struttura di base, che si chiamer\u00e0, ad esempio, base.sql<\/code> <\/li>\n
    2. Applicazione delle migrazioni<\/li>\n
    3. Chiamata deployDump<\/code><\/li>\n<\/ol>\n

      <\/p>\n

      base.sql<\/code> \u00e8 il punto di partenza, su cui vengono applicate le migrazioni e viene eseguito deployDump<\/code>, cio\u00e8 base.sql + migrazioni + deployDump = struttura attuale del database<\/code>. Un file di questo tipo pu\u00f2 essere generato con il supporto di un'utilit\u00e0. pg_dump<\/code>Utilizzato base.sql<\/code> esclusivamente durante l'inizializzazione del database da zero.<\/p><\/blockquote>\n

      Chiameremo lo script per l'inizializzazione completa del database refresh.sh<\/code>. Il processo di lavoro pu\u00f2 apparire come segue:<\/p>\n

      <\/p>\n

        \n
      1. Lo sviluppatore esegue nel proprio ambiente refresh.sh<\/code> e ottiene la struttura attuale del database<\/li>\n
      2. Lo sviluppatore inizia a lavorare sul compito assegnato, modificando il database locale per soddisfare le esigenze della nuova funzionalit\u00e0 (ALTER TABLE ... ADD COLUMN<\/code> ecc.)<\/li>\n
      3. Dopo aver completato il compito, lo sviluppatore chiama la funzione saveDump<\/code>, per registrare in VCS le modifiche apportate al database<\/li>\n
      4. Lo sviluppatore esegue nuovamente refresh.sh<\/code>, quindi verifyDump<\/code>, che ora mostra l'elenco delle modifiche da includere nella migrazione<\/li>\n
      5. Lo sviluppatore trasferisce tutte le modifiche della struttura nel file di migrazione, esegue di nuovo refresh.sh<\/code> e verifyDump<\/code>, e, se la migrazione \u00e8 stata compilata correttamente, verifyDump<\/code> mostrer\u00e0 l'assenza di differenze tra il database locale e il dump salvato<\/li>\n<\/ol>\n

        <\/p>\n

        Il processo descritto sopra \u00e8 compatibile con i principi di gitflow. Ogni branch nel VCS conterr\u00e0 la propria versione del dump, e durante la fusione dei branch si verificher\u00e0 una fusione dei dump. Nella maggior parte dei casi, dopo la fusione non \u00e8 necessario intraprendere ulteriori azioni, ma se sono state apportate modifiche in branch diversi, ad esempio nella stessa tabella, potrebbe sorgere un conflitto.<\/p>\n

        <\/p>\n

        Consideriamo una situazione di conflitto, ad esempio: c'\u00e8 un branch develop.<\/em>, da cui si diramano due branch: feature1<\/em> e feature2<\/em>, che non hanno conflitti con develop.<\/em>, ma hanno conflitti tra di loro. \u00c8 necessario effettuare la fusione di entrambi i branch in develop.<\/em>. In questo caso, \u00e8 consigliabile prima eseguire la fusione di uno dei branch in develop.<\/em>, e poi effettuare la fusione develop.<\/em> nell'altro branch, risolvendo i conflitti in quest'ultimo branch, dopodich\u00e9 eseguire la fusione dell'ultimo branch in develop.<\/em>. Durante la fase di risoluzione dei conflitti, potrebbe essere necessario correggere il file di migrazione nell'ultimo branch per farlo corrispondere al dump finale, che include i risultati delle fusioni.<\/p>\n

        <\/p>\n

        Come implementare in modo sicuro un numero maggiore di modifiche alla struttura del database nell'ambiente di produzione<\/h2>\n

        <\/p>\n

        Grazie alla disponibilit\u00e0 nel VCS di un dump della struttura attuale del database, diventa possibile verificare il database di produzione per la corrispondenza esatta con la struttura richiesta. Questo garantisce che tutte le modifiche previste dagli sviluppatori siano state trasferite con successo nel database di produzione.<\/p>\n

        <\/p>\n

        Poich\u00e9 DDL<\/a><\/noindex> in PostgreSQL \u00e8 transazionale<\/a><\/noindex>, si raccomanda di seguire il seguente ordine di deployment, in modo che, in caso di errore imprevisto, si possa eseguire senza problemi ROLLBACK<\/code>:<\/p>\n

        <\/p>\n

          \n
        1. Iniziare la transazione<\/li>\n
        2. Eseguire tutte le migrazioni nella transazione<\/li>\n
        3. Nella stessa transazione eseguire deployDump<\/code><\/li>\n
        4. Senza chiudere la transazione, eseguire verifyDump<\/code>. Se non ci sono errori, eseguire COMMIT<\/code>. Se ci sono errori, eseguire ROLLBACK<\/code><\/li>\n<\/ol>\n

          <\/p>\n

          Questi passaggi si integrano abbastanza facilmente nei metodi esistenti per il deployment delle applicazioni, inclusi quelli a zero downtime.<\/p>\n

          <\/p>\n

          Conclusione<\/h1>\n

          <\/p>\n

          Grazie ai metodi descritti sopra, \u00e8 possibile ottenere il massimo dalle performance dei progetti \"PHP + PostgreSQL\", sacrificando per\u00f2 relativamente poca comodit\u00e0 nello sviluppo rispetto all'implementazione di tutta la logica di business nel codice principale dell'applicazione. Inoltre, l'elaborazione dei dati in PL\/pgSQL<\/a><\/noindex> spesso appare pi\u00f9 trasparente e richiede meno codice rispetto alla stessa funzionalit\u00e0 scritta in PHP.<\/p>\n

          Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

          \u0426\u0435\u043b\u044c \u0434\u0430\u043d\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 \u043d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0435 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a\u0438 schema-keeper \u043f\u043e\u043a\u0430\u0437\u0430\u0442\u044c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0442 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e \u043e\u0431\u043b\u0435\u0433\u0447\u0438\u0442\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 PHP-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0449\u0438\u0445 \u0421\u0423\u0411\u0414 PostgreSQL. \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f \u0438\u0437 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438, \u0432 \u043f\u0435\u0440\u0432\u0443\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c, \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043b\u0435\u0437\u043d\u0430 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430\u043c, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u043e \u043c\u0430\u043a\u0441\u0438\u043c\u0443\u043c\u0443 \u0445\u043e\u0442\u044f\u0442 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 PostgreSQL, \u043d\u043e \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u0441 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0441\u043e\u043f\u0440\u043e\u0432\u043e\u0436\u0434\u0435\u043d\u0438\u044f \u0431\u0438\u0437\u043d\u0435\u0441-\u043b\u043e\u0433\u0438\u043a\u0438, \u0432\u044b\u043d\u0435\u0441\u0435\u043d\u043d\u043e\u0439 \u0432 \u0411\u0414. \u0421\u0442\u0430\u0442\u044c\u044f \u043d\u0435 \u0431\u0443\u0434\u0435\u0442 \u043e\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c \u043f\u0440\u0435\u0438\u043c\u0443\u0449\u0435\u0441\u0442\u0432\u0430 […]<\/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-31385","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\udd47Logica aziendale nel database con SchemaKeeper | ProHoster","description":"L'obiettivo di questo articolo \u00e8 mostrare, attraverso la libreria schema-keeper, gli strumenti che consentono di farlo in modo sostanziale.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/biznes-logika-v-baze-dannyh-pri-pomoshhi-schemakeeper","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\u0411\u0438\u0437\u043d\u0435\u0441-\u043b\u043e\u0433\u0438\u043a\u0430 \u0432 \u0431\u0430\u0437\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u0440\u0438 \u043f\u043e\u043c\u043e\u0449\u0438 SchemaKeeper | ProHoster","og:description":"\u0426\u0435\u043b\u044c \u0434\u0430\u043d\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 \u043d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0435 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a\u0438 schema-keeper \u043f\u043e\u043a\u0430\u0437\u0430\u0442\u044c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0442 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/biznes-logika-v-baze-dannyh-pri-pomoshhi-schemakeeper","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-10-31T18:40:58+00:00","article:modified_time":"2019-10-31T18:40:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31385","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-21 05:54:24","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:17:26","updated":"2026-01-21 05:54:24","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\/31385","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=31385"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31385\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=31385"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=31385"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=31385"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}