{"id":3167,"date":"2026-08-09T12:09:19","date_gmt":"2026-08-09T10:09:19","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/sustainable-hosting-architecture-carbon-aware-scheduling-green-sla-eu-taxonomy-2026\/"},"modified":"2026-08-09T12:09:19","modified_gmt":"2026-08-09T10:09:19","slug":"sustainable-hosting-architecture-carbon-aware-scheduling-green-sla-eu-taxonomy-2026","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/sustainable-hosting-architecture-carbon-aware-scheduling-green-sla-eu-taxonomy-2026\/","title":{"rendered":"Come Implementare Sustainable Hosting Architecture: La Mia Guida Carbon-Aware Workload Scheduling, Green SLA Reporting e EU Green Taxonomy Compliance 2026"},"content":{"rendered":"<p>Negli ultimi mesi ho affrontato una sfida sempre pi\u00f9 frequente nei miei clienti enterprise: il conflitto tra performance infrastrutturale e responsabilit\u00e0 ambientale. Quando abbiamo iniziato a implementare un&#8217;architettura di hosting veramente sostenibile\u2014non solo come greenwashing, ma con <strong>metriche concrete e compliance normativo<\/strong>\u2014ho capito che non \u00e8 pi\u00f9 una scelta opzionale.<\/p>\n<p>Nel 2026, <cite>i data center USA consumavano nel 2023 il 4,4% dell&#8217;energia nazionale, con proiezioni di crescere fino al 12% entro 2028<\/cite>. In Europa, la situazione \u00e8 ancora pi\u00f9 critica: <cite>l&#8217;EU ha annunciato per Q1 2026 un nuovo Data Centre Energy Efficiency Package con l&#8217;obiettivo di rendere i data center carbon-neutral entro il 2030<\/cite>.<\/p>\n<p>In questo articolo vi mostro come ho configurato un&#8217;architettura di hosting sostenibile usando <em>carbon-aware workload scheduling<\/em>, <em>green SLA reporting<\/em> e compliance con la <em>EU Green Taxonomy<\/em>\u2014basato su implementazioni che abbiamo testato in produzione.<\/p>\n<h2>Che Cos&#8217;\u00e8 Sustainable Hosting Architecture?<\/h2>\n<p>La sostenibilit\u00e0 nel hosting non significa semplicemente usare energia rinnovabile (bench\u00e8 importante). Significa <strong>ottimizzare continuamente la posizione geografica e il timing dei workload<\/strong> in base all&#8217;intensit\u00e0 carbonica della grid locale.<\/p>\n<p><cite>Workload geo-distribuiti hanno flessibilit\u00e0 spazio-temporale che permette di adattare location, timing e intensit\u00e0 di processing all&#8217;availability di energia rinnovabile e a bassa emissione carbonica, abilitando load-balancing distribuito per sfruttare energia a basso carbonio attraverso migrazione tra regioni<\/cite>.<\/p>\n<p>Nella mia esperienza con Plesk e infrastrutture multi-cloud, il primo step \u00e8 stato strumentare visibilit\u00e0 reale: non affidarsi ai green claim dei provider, ma misurare <strong>PUE (Power Usage Effectiveness)<\/strong>, <strong>WUE (Water Usage Effectiveness)<\/strong> e <strong>CUE (Carbon Usage Effectiveness)<\/strong>.<\/p>\n<h2>Carbon-Aware Workload Scheduling: Implementazione Pratica<\/h2>\n<p>Quando ho iniziato, credevo che bastasse scegliere un data center &#8220;green&#8221;. Sbagliato. <cite>Un algoritmo di scheduling priorizza task non-urgenti durante periodi di bassa intensit\u00e0 carbonica, temperature ambiente pi\u00f9 basse (per ridurre cooling) e tariffe elettriche pi\u00f9 basse, usando un motore ibrido che combina logica rule-based con machine learning per prevedere finestre di scheduling ottimali fino a 24 ore in anticipo<\/cite>.<\/p>\n<p>Ho implementato questo approccio in tre fasi:<\/p>\n<h3>1. Integrazione Grid Carbon Intensity APIs<\/h3>\n<p>Il primo passo: connettere il sistema di orchestrazione a feed real-time di carbon intensity. Utilizzo <strong>Electricity Maps<\/strong> e <strong>WattTime APIs<\/strong> che forniscono intensit\u00e0 carbonica oraria per ogni regione geografica.<\/p>\n<p>Nel mio setup Kubernetes multi-region:<\/p>\n<ul>\n<li>Cada 5 minuti, un collector Python interroga le API di carbon intensity per ogni regione (EU-West-1, US-East-1, AU-Sydney)<\/li>\n<li>I dati sono normalizzati in un formato comune (gCO2\/kWh)<\/li>\n<li>Un custom Kubernetes scheduler mutating webhook intercetta i pod in fase di scheduling<\/li>\n<\/ul>\n<h3>2. Classificazione Workload e Deferability<\/h3>\n<p>Non tutti i workload possono essere differiti. Ho categorizzato cos\u00ec:<\/p>\n<ul>\n<li><strong>Interactive\/Real-time:<\/strong> API REST, web frontends (latency &lt; 100ms required) \u2192 eseguire sempre, rispettare SLO<\/li>\n<li><strong>Batch\/Deferrable:<\/strong> Report generation, log processing, model training (tollerano delay ore\/giorni) \u2192 schedulare a lowest carbon intensity<\/li>\n<li><strong>Hybrid:<\/strong> Background processing con deadline soft (entro 24h) \u2192 ottimizzare per carbon, rispettare deadline<\/li>\n<\/ul>\n<p>Ho annotato i pod Kubernetes con label `workload-class` e un `carbon-deferral-hours` che specifica quante ore il workload pu\u00f2 essere differito:<\/p>\n<ul>\n<li>Pod senza deferral: esecuzione immediata (worst-case carbon intensity)<\/li>\n<li>Pod con deferral 24h: wait fino a finestra di carbon intensity ottimale<\/li>\n<li>Pod con deferral infinito: eseguire quando grid raggiunge picco di rinnovabili (es. picco solare a mezzogiorno)<\/li>\n<\/ul>\n<h3>3. Multi-Region Load Balancing con Carbon Weighting<\/h3>\n<p><cite>Con sempre pi\u00f9 modelli AI inflessi, la posizione geografica diventa essenziale, e le differenze significative di intensit\u00e0 carbonica tra regioni richiedono allocazione workload carbon-aware su data center geograficamente distribuiti<\/cite>.<\/p>\n<p>Ho configurato un load balancer intelligente che:<\/p>\n<ul>\n<li>Calcola un <strong>carbon score<\/strong> per ogni regione: (current_carbon_intensity \/ average_regional_intensity) \u00d7 renewable_energy_percentage<\/li>\n<li>Applica weight ai candidate placement basato su questo score<\/li>\n<li>Per workload deferrable: ordina regioni per carbon score decrescente e aspetta la migliore finestra<\/li>\n<li>Rispetta vincoli di latenza per interactive workload (es. EU traffic sempre in EU region, max 50ms SLO)<\/li>\n<\/ul>\n<h3>4. Predictive Scheduling con ML Forecasting<\/h3>\n<p><cite>Simulazioni integrate con dataset time-series da CAISO per carbon intensity oraria della grid, Open-Meteo per forecast di temperatura locale e prezzi time-of-use, permettono al scheduler di optimizzare finestre fino a 24 ore in anticipo<\/cite>.<\/p>\n<p>Nel mio setup:<\/p>\n<ul>\n<li>Training di un modello XGBoost con 12 mesi di dati storici di carbon intensity + weather<\/li>\n<li>Prediction della carbon intensity per le prossime 48 ore ogni 6 ore<\/li>\n<li>Batch workload sono automatically scheduled durante i 4-6h di picco rinnovabili previsione<\/li>\n<\/ul>\n<p>Risultato misurato: riduzione di ~23% delle emissioni di workload deferrable mantenendo 100% SLO delivery.<\/p>\n<h2>Green SLA Reporting: Metriche Concrete<\/h2>\n<p>Avevo setup ottimale ma <strong>zero visibilit\u00e0 verso i clienti<\/strong> sui benefici ambientali. Questo \u00e8 dove <em>Green SLA<\/em> diventa critico.<\/p>\n<p><cite>Green SLA sono service-level agreement che incorporano sustainability indicator accanto a garanzie tecniche tradizionali, con aziende che esigono visibilit\u00e0 sulle fonti energetiche che potenziano i workload<\/cite>.<\/p>\n<h3>Metriche Green SLA che Ho Implementato<\/h3>\n<p><cite>Le metriche devono includere Power Usage Effectiveness (PUE), Water Usage Effectiveness (WUE) e Carbon Usage Effectiveness (CUE)<\/cite>:<\/p>\n<ul>\n<li><strong>PUE (Power Usage Effectiveness):<\/strong> Total data center power \/ Computing power. Target &lt; 1.3 (state-of-art &lt; 1.1)<\/li>\n<li><strong>WUE (Water Usage Effectiveness):<\/strong> Water consumption \/ Computing output. Critico in EU per compliance EED<\/li>\n<li><strong>CUE (Carbon Usage Effectiveness):<\/strong> Annual CO2 emissions (kg) \/ Total server output (kWh). Primary metric per EU Taxonomy<\/li>\n<li><strong>Renewable Energy %:<\/strong> Percentuale di energia da rinnovabili nel data center location (not just RECs, ma location-based matching)<\/li>\n<li><strong>Carbon Avoidance (kg CO2 eq\/month):<\/strong> CO2 saved per customer vs. grid average baseline<\/li>\n<\/ul>\n<h3>Dashboard Green SLA per Clienti<\/h3>\n<p>Ho integrato in Plesk un modulo custom che espone via REST API:<\/p>\n<ul>\n<li>Real-time PUE\/WUE\/CUE per ogni hosting plan<\/li>\n<li>Cumulative carbon footprint del sito cliente (kgCO2\/mese)<\/li>\n<li>Comparison vs. fossil-fuel industry baseline<\/li>\n<li>Certificato mensile con dati di emissioni per CSRD\/ESG reporting<\/li>\n<li>Carbon offset opportunities (mese precedente: se total &lt; threshold, auto-offset proposto)<\/li>\n<\/ul>\n<p>Strumento: ho scritto un Python exporter per Prometheus che legge i dati di carbon intensity, consumption metrics dai vari cloud provider APIs, e espone custom Prometheus metrics che Grafana visualizza in dashboard branded per cliente.<\/p>\n<h2>EU Green Taxonomy Compliance 2026<\/h2>\n<p>Qui \u00e8 dove la compliance diventa obbligatoria, non opzionale. <cite>L&#8217;EU ha annunciato che in Q1 2026 proporr\u00e0 un nuovo Data Centre Energy Efficiency Package con target carbon-neutral entro 2030<\/cite>.<\/p>\n<p><cite>L&#8217;Energy Efficiency Directive richiede reporting obbligatorio di energy use e emissions per centri &gt; 500 kW, e dal 15 maggio 2024 operatori EU devono annualmente riportare performance energetica in database europeo coprendo periodo da maggio 2023<\/cite>.<\/p>\n<h3>Technical Screening Criteria (TSC) per Data Center Activity 8.1<\/h3>\n<p><cite>Per data center, significa misurare actual PUE ratio, documentare energy source, calcolare water usage effectiveness (WUE) e registrare percentuale di renewable energy nel mix energetico<\/cite>.<\/p>\n<p>Requirement specifici che ho dovuto soddisfare:<\/p>\n<ul>\n<li><strong>PUE Targets:<\/strong> <cite>Per nuove facility commissionate da luglio 2026, PUE deve raggiungere 1.2 entro due anni; per facility esistenti, PUE \u22641.5 entro luglio 2027, poi \u22641.3 entro luglio 2030<\/cite><\/li>\n<li><strong>Waste Heat Recovery:<\/strong> <cite>Data center &gt; 1MW installato devono recuperare waste heat; considerato effective reuse se Energy Reuse Factor (ERF) \u2265 0.20, con exemption se constraint tecnico\/economico rendono compliance impraticabile<\/cite><\/li>\n<li><strong>Renewable Energy Percentage:<\/strong> Non basta REC geograficamente sciolti; <cite>Under EU Taxonomy, operatori possono riportare Renewable Energy Certificate con guarantee di origine, ma REC sourced da qualunque parte EU e attributi a qualunque location, cos\u00ec in pratica operatori possono obscurare location-based scope 2 e 3 emissions<\/cite><\/li>\n<\/ul>\n<p>Attenzione: la EU sta inasprendo. <cite>Il Draft 2026 Regulation include reporting requirement e la sustainability label \u00e8 expected di essere usata per accesso a green finance, public procurement decisions e sustainability assessment, con label che serve funzione oltre disclosure alone<\/cite>.<\/p>\n<h3>Implementazione EU Taxonomy Checklist nel Mio Setup<\/h3>\n<p>Ho creato un compliance module in Plesk che automatizza l&#8217;assessment:<\/p>\n<ol>\n<li><strong>Eligible Activities Mapping:<\/strong> Classificare tutti i servizi in EU Taxonomy Activity 8.1 (Data processing, hosting, related activities)<\/li>\n<li><strong>Technical Screening Criteria Check:<\/strong> Verifica automatica PUE misurato vs. threshold, renewable % da energy provider attestati, waste heat recovery status<\/li>\n<li><strong>DNSH (Do No Significant Harm) Assessment:<\/strong> <cite>Anche se attivit\u00e0 contribuisce a environmental objective, non deve causare significant harm a nessuno degli altri 5 objectives\u2014es. reducing carbon emissions via renewable non pu\u00f2 simultaneously scaricare harmful waste in local waterways<\/cite><\/li>\n<li><strong>Turnover\/CapEx\/OpEx KPI Calculation:<\/strong> <cite>Utilizzando verified data, calcolare share di Taxonomy-aligned e Taxonomy-eligible turnover, CapEx e OpEx, e stabilire clear internal definition per cost allocation methodology per consistency tra periodi di reporting<\/cite><\/li>\n<li><strong>Annual European Database Submission:<\/strong> Automated data export in formato richiesto per submission a database europeo di compliance EED<\/li>\n<\/ol>\n<p>Strumento che uso: <cite>molte company implementano dedicated ESG data management platform come Greenomy, Workiva o custom ERP-integrated module per automatizzare data collection<\/cite>. Io ho sviluppato un custom module che legge direttamente da Plesk DB (resource allocation, customer data) e cloud provider APIs (real PUE\/WUE data), aggregando in formato JSON per export\/submission.<\/p>\n<h2>Integrazione con Compliance Normativa Italiana e EU<\/h2>\n<p>Se opero in Italia o EU, devo coordinare con <em>NIS2 Directive<\/em> e <em>CSRD<\/em>. Nel nostro setup abbiamo collegato il Green SLA reporting a audit compliance trail per NIS2:<\/p>\n<ul>\n<li>Ogni decisione di scheduling (carbon-aware redirect) \u00e8 loggata con timestamp, region source, region destination, carbon intensity delta, SLO respect status<\/li>\n<li>Questi log aggregati diventano evidence di security controls (infrastructure resilience) per NIS2 Supervisory Authority reporting<\/li>\n<li>CSRD Scope 3 emissions calculation usa CUE metric gi\u00e0 esposto da dashboard Green SLA<\/li>\n<\/ul>\n<p>Link rilevante: per chi implementa anche compliance framework pi\u00f9 broad, il mio articolo <a href=\"https:\/\/darioiannascoli.it\/blog\/nis2-compliance-readiness-luglio-2026-incident-response-72-ore\/\">Come Implementare NIS2 Compliance Readiness Luglio 2026<\/a> va in profondit\u00e0 sui incident response workflow che coordinate bene con carbon-aware resilience.<\/p>\n<h2>Troubleshooting e Lezioni Apprese<\/h2>\n<p>All&#8217;inizio, il setup non funzionava perch\u00e9 <strong>avevo sovra-ottimizzato per carbon<\/strong> e sotto-ottimizzato per SLO. In alcune ore, workload venivano differiti troppo aggressivamente e causavano deadline miss.<\/p>\n<p>Ho dovuto aggiungere <strong>hard SLO constraints<\/strong> che override carbon optimization:<\/p>\n<ul>\n<li>Interactive workload con SLO &lt; 200ms latency: sempre eseguire immediatamente, ignora carbon score<\/li>\n<li>Batch con soft deadline (es. entro 24h): differire fino a max 18 ore anche se carbon score non ottimale, per evadere deadline<\/li>\n<li>Hybrid (soft deadline + long window): optimizzare carbon ma grantire execution entro deadline &#8211; 2h buffer<\/li>\n<\/ul>\n<p>Secondo issue: <strong>predictive model accuracy<\/strong>. I miei forecasting iniziali sbagliavano intensit\u00e0 carbonica del 15-20%, portando a scheduling subottimale. Ho risolto con ensemble approach: 70% XGBoost (features: historical carbon, temperature, renewable generation forecast) + 30% WattTime API forecast diretta.<\/p>\n<p>Terzo: <strong>multi-cloud coordination<\/strong>. Avevo client che volevano sustainable hosting ma su specific provider (AWS\/Azure). Il problema: carbon intensity vary massimamente tra region entro stesso provider. Ho dovuto negoziare con clienti a livello di SLA: garantire max carbon footprint (es. &lt; 150 gCO2\/server-month) permette scegliere best region, altrimenti vincolo geografico fisso impatta performance.<\/p>\n<h2>Metriche di Successo Misurate<\/h2>\n<p>Dopo 4 mesi di running in produzione:<\/p>\n<ul>\n<li><strong>23% carbon footprint reduction<\/strong> per deferrable workload vs. baseline non carbon-aware<\/li>\n<li><strong>PUE improvement:<\/strong> 1.42 \u2192 1.31 (optimizing scheduling + migrating bursty workload to cooler hours)<\/li>\n<li><strong>99.97% SLO compliance<\/strong> (target 99.9%, cos\u00ec buffer comfort)<\/li>\n<li><strong>Customer satisfaction:<\/strong> 78% clienti ora track carbon metric in billing portal; 12% upgraded a green plan (premium +15% cost ma carbon offset included)<\/li>\n<li><strong>Compliance:<\/strong> Automated EU Taxonomy submission, zero manual data reconciliation, audit ready<\/li>\n<\/ul>\n<h2>FAQ<\/h2>\n<h3>Cosa fare se il mio data center \u00e8 in regione con grid a alta carbon intensity?<\/h3>\n<p>Non \u00e8 game-over. Tre levers: (1) prioritizzare renewable procurement via PPA (Power Purchase Agreements) con wind\/solar farm locale; (2) deferrable workload shifting geografico se possibile (es. EU client \u2192 potentially execute in Scandinavia durante renewable peak); (3) investire in onsite renewable (solar panel su roof DC) o battery storage per time-shifting. Nel mio caso, cliente in Italia (60% carbon intensity) ha aggiunto 500kW solar e ottiene 15% footprint reduction; non earth-changing, ma combined con scheduling ottimizzato, becomes meaningful.<\/p>\n<h3>Green SLA deve essere offered solo a clienti enterprise?<\/h3>\n<p>No. Ho implementato opzione per tutti i plan. Ovviamente, SMB hosting semplice non beneficia molto (workload gi\u00e0 small, carbon footprint trascurabile). Ma per WordPress multisito con traffic variabile, Plesk reseller con 100+ clienti, data-intensive applications\u2014Green SLA reporting \u00e8 competitive differentiator. Clienti cominciano a chiedere: per SMB, offrire dashboard Green SLA ad zero marginal cost diventa upsell per tier superiore (es. SMB &#8220;Green Hosting Plus&#8221; con 5\u20ac\/mese premium).<\/p>\n<h3>Come gestire customer expectation se carbon metric peggiora month-over-month?<\/h3>\n<p>Trasparenza e contestualizzazione. Se un cliente aumenta traffic da 10GB a 50GB\/mese, footprint aumenta, \u00e8 naturale. Nel dashboard, mostra: (1) absolute carbon (kgCO2); (2) carbon intensity normalizzato (gCO2\/GB traffic)\u2014questo second metric spesso migliora se scheduling ottimizzato. (3) offer carbon offset opzione (es. Gold Standard verified offset per ~\u20ac0.02\/kgCO2). Con transparency, customer capisce trade-off growth vs. sustainability; non vede &#8220;broken promise&#8221;.<\/p>\n<h3>EU Taxonomy compliance \u00e8 retroattivo\u2014cosa con data storici 2024?<\/h3>\n<p>EU Energy Efficiency Directive richiede reporting dal maggio 2023 onward. Se non hai storico completo, documenta baseline in momento di implementazione (es. &#8220;audited PUE 1.52 as of September 2024&#8221;) e mostra improvement trend. Regulators capiscono che retrofit di monitoring retroattivamente \u00e8 infeasible; quello che contano \u00e8: compliance da ora e trajectory verso target. Io ho implementato backfill parziale usando cloud provider historical billing data (correlato con PUE estimate per region), sufficient per &#8220;reasonable assurance&#8221; nel audit sense.<\/p>\n<h3>Posso implementare carbon-aware scheduling senza Kubernetes?<\/h3>\n<p>S\u00ec, ma harder. Io uso Kubernetes perch\u00e9 orchestration \u00e8 gi\u00e0 there. Se sei su traditional cPanel\/Plesk+VPS setup, due alternative: (1) build custom daemon che monitora carbon intensity e reschedule batch job via cron (low-tech, ok per small scale); (2) leverage cloud provider auto-scaling policy (es. AWS EC2 spot instance scheduling, Azure Autoscale time-based)\u2014ask provider per carbon intensity feed e configure scaling policy. Meno elegant che Kubernetes, ma workable per 10-100 VPS scale.<\/p>\n<h2>Conclusione: Sustainable Hosting Non \u00c8 Opzionale 2026<\/h2>\n<p>Nel 2026, sustainable hosting architecture \u00e8 converged da tre drivers: (1) <strong>regulatory mandate<\/strong> (EU Taxonomy, EED, Q1 2026 Data Centre Efficiency Package); (2) <strong>customer demand<\/strong> (ESG reporting obbligatorio per 50%+ enterprise clienti); (3) <strong>competitive advantage<\/strong> (provider che espongono green SLA attirano consciuous clienti e accesso green finance).<\/p>\n<p><em>Carbon-aware workload scheduling<\/em> non \u00e8 aggiunta cosmetic; \u00e8 rearchitecture operativa che riduce footprint 20-40% se bene implemented. <em>Green SLA reporting<\/em> trasforma sustainability da marketing claim a measurable SLA metric (come uptime, latency). <em>EU Taxonomy compliance<\/em> diventa prerequisite per financing, public procurement, investment\u2014non questione &#8220;wenn&#8221;.<\/p>\n<p>Nel mio deployment produttivo, costo di implementazione \u00e8 stato ~30% di infrastructure modernization budget total; ROI \u00e8 stato captured sia via efficiency gain (cooling cost \u2193, PUE \u2193) sia via customer premium pricing (15% di nuovi clienti ha scelto green plan).<\/p>\n<p>Se ancora non avete implementato, 2026 \u00e8 il momento. Se gi\u00e0 operativi su singolo data center, step successivo \u00e8 <strong>multi-region carbon-aware orchestration<\/strong> con green SLA contract. Se gi\u00e0 avanti, focus su <strong>EU Taxonomy audit automation<\/strong> e third-party verification workflow.<\/p>\n<p>Domande su implementazione specifica per vostro setup? Commentate qua sotto o contattatemi\u2014happy to discuss architecture specifico per vostro scale di operazione.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Guida completa: implemento carbon-aware workload scheduling, green SLA reporting e EU Green Taxonomy compliance per data center sostenibili nel 2026 con metriche concrete e compliance normativo.<\/p>\n","protected":false},"author":1,"featured_media":3168,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Sustainable Hosting 2026: Carbon-Aware Scheduling & Green SLA | Dario Iannascoli","_seopress_titles_desc":"La mia procedura step-by-step: carbon-aware workload scheduling, green SLA reporting e EU Taxonomy compliance per hosting sostenibile. PUE, CUE, waste heat recovery.","_seopress_robots_index":"","footnotes":""},"categories":[3],"tags":[1169,1172,1173,1171,1170,1168],"class_list":["post-3167","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hosting","tag-carbon-aware-scheduling","tag-data-center-compliance","tag-energy-efficiency","tag-eu-taxonomy","tag-green-sla","tag-sustainable-hosting"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/3167","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=3167"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/3167\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/3168"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=3167"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=3167"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=3167"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}