{"id":883,"date":"2021-07-02T10:19:00","date_gmt":"2021-07-02T08:19:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/api-gateway-confronto-2021\/"},"modified":"2021-07-02T10:19:00","modified_gmt":"2021-07-02T08:19:00","slug":"api-gateway-confronto-2021","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/api-gateway-confronto-2021\/","title":{"rendered":"API Gateway: confronto 2021 (Kong, Apigee, AWS)"},"content":{"rendered":"

Quando un’applicazione moderna espone decine o centinaia di API<\/strong>, gestirle senza un punto di controllo centralizzato diventa rapidamente un incubo. Autenticazione duplicata in ogni microservizio, rate limiting implementato in modo difforme, log sparsi su sistemi diversi, versioning gestito a mano: chiunque abbia provato a scalare un’architettura a microservizi conosce questo dolore. La risposta a questi problemi si chiama API gateway<\/strong>.<\/p>\n

In questa guida confrontiamo le principali soluzioni di API gateway disponibili nel 2021 \u2014 Kong API gateway<\/strong>, Tyk<\/strong>, AWS API Gateway<\/strong>, Azure API Management e Apigee gateway<\/strong> \u2014 analizzando funzionalit\u00e0, costi, casi d’uso e criteri di scelta. L’obiettivo \u00e8 offrire a CTO, IT manager, developer senior e DevOps engineer un riferimento operativo per orientarsi tra opzioni open source e commerciali, evitando errori di valutazione che si pagano poi in produzione.<\/p>\n

\"API
Routing intelligente delle richieste API tra client e microservizi<\/figcaption><\/figure>\n

API gateway: cosa \u00e8 e perch\u00e9 serve<\/h2>\n

Un API gateway<\/strong> \u00e8 un componente software che si frappone tra i client (browser, app mobile, sistemi terzi) e i servizi backend. Tutte le richieste passano attraverso il gateway, che si occupa di instradarle al servizio corretto, applicare regole di sicurezza, controllare i flussi di traffico e raccogliere metriche. \u00c8 il “front door” delle API, il punto unico in cui concentrare logiche trasversali che altrimenti finirebbero replicate in ogni microservizio.<\/p>\n

L’esigenza nasce con l’affermazione delle architetture a microservizi. Un monolite espone tipicamente una manciata di endpoint pubblici; un sistema a microservizi pu\u00f2 avere decine di servizi, ciascuno con la propria API. Senza un gateway, ogni client dovrebbe conoscere l’indirizzo di ogni servizio, gestire l’autenticazione separatamente, implementare retry e circuit breaker. Il gateway astrae questa complessit\u00e0: i client parlano con un solo endpoint stabile, mentre dietro le quinte l’architettura pu\u00f2 evolvere liberamente.<\/p>\n

Per chi si sta avvicinando al mondo delle API \u00e8 utile partire dalla nostra guida di base “Cos’\u00e8 una API REST” (link interno: guida non sviluppatori<\/a>): il gateway \u00e8 il livello successivo, lo strumento che entra in gioco quando le API smettono di essere uno strato tecnico e diventano un prodotto da governare.<\/p>\n

Le 7 funzionalit\u00e0 essenziali di un API gateway<\/h2>\n

Non tutti gli API gateway sono uguali. Esistono prodotti minimali pensati per il routing di base e piattaforme complete che includono portali developer, marketplace e analytics avanzate. Le funzionalit\u00e0 che dovrebbero essere presenti in qualsiasi soluzione professionale sono sette.<\/p>\n

1. Routing intelligente.<\/strong> Il gateway riceve una richiesta su un percorso (ad esempio \/api\/v2\/orders<\/code>) e la inoltra al servizio backend corretto. Le regole di routing possono basarsi su path, header, parametri di query, hostname o versione dell’API. Routing avanzato include canary deployment, blue-green deployment, traffic mirroring per testare nuove versioni in produzione su una percentuale del traffico.<\/p>\n

2. Rate limiting e throttling.<\/strong> Limitare il numero di richieste per client, per API key, per IP o per utente \u00e8 essenziale per proteggere i servizi backend da picchi accidentali o attacchi DoS. Le policy tipiche prevedono finestre temporali (richieste al secondo, al minuto, all’ora) e differenziazione per piano commerciale (free tier vs paid tier).<\/p>\n

3. Autenticazione e autorizzazione.<\/strong> Il gateway centralizza la verifica delle credenziali: API key, OAuth 2.0, JWT, mutual TLS, integrazione con identity provider esterni (Okta, Auth0, Keycloak). I servizi backend ricevono richieste gi\u00e0 autenticate, riducendo la superficie di attacco e semplificando la logica applicativa.<\/p>\n

4. Trasformazione di request e response.<\/strong> Il gateway pu\u00f2 modificare il payload prima di inoltrarlo al backend o prima di restituirlo al client: aggiungere o rimuovere header, convertire XML in JSON, adattare formati legacy. Questa funzionalit\u00e0 \u00e8 cruciale per esporre API moderne sopra sistemi datati senza dover modificare il codice esistente.<\/p>\n

\"API
Soluzioni managed AWS, Azure e Apigee in confronto<\/figcaption><\/figure>\n

5. Caching delle risposte.<\/strong> Risposte a richieste GET possono essere memorizzate sul gateway e servite direttamente, evitando di colpire il backend. Per API ad alto traffico con dati che cambiano lentamente (cataloghi, configurazioni, dati di riferimento) il caching riduce drasticamente latenza e carico.<\/p>\n

6. Monitoring e observability.<\/strong> Il gateway \u00e8 il punto naturale dove raccogliere metriche aggregate: numero di chiamate per endpoint, latenza media, error rate, status code distribution. Integrazione con Prometheus, Grafana, ELK Stack, Datadog \u00e8 ormai standard. Senza monitoring centralizzato \u00e8 impossibile capire cosa sta accadendo a livello di API.<\/p>\n

7. Sicurezza applicativa.<\/strong> WAF integrato, protezione contro injection, rilevamento di pattern anomali, IP whitelisting\/blacklisting, validazione di schema (OpenAPI\/Swagger). La sicurezza al livello del gateway \u00e8 il primo strato di difesa; per approfondire il tema rimandiamo all’articolo dedicato alle best practice di API security<\/a>.<\/p>\n

Open source vs commerciali: pro e contro<\/h2>\n

La scelta tra una soluzione open source self-hosted e un servizio gestito commerciale \u00e8 probabilmente la decisione architetturale pi\u00f9 rilevante. Ci sono vantaggi e svantaggi su entrambi i fronti.<\/p>\n

Le soluzioni open source<\/strong> (Kong Community, Tyk Open Source, KrakenD, Express Gateway) offrono pieno controllo: nessun vendor lock-in, possibilit\u00e0 di personalizzare il codice, costi di licenza zero. Lo svantaggio \u00e8 il costo operativo nascosto: serve un team in grado di installare, aggiornare, monitorare, scalare il gateway. Per realt\u00e0 piccole questo costo pu\u00f2 superare quello di un servizio gestito.<\/p>\n

Le soluzioni commerciali managed<\/strong> (AWS API Gateway, Azure API Management, Apigee, Kong Konnect) offrono setup rapido, SLA, supporto dedicato, integrazione nativa con il resto dell’ecosistema cloud. Il rovescio della medaglia \u00e8 il vendor lock-in (migrare da AWS API Gateway a Kong richiede sforzo significativo) e costi che crescono con il volume di traffico, talvolta in modo non lineare.<\/p>\n

Il criterio di scelta non \u00e8 ideologico ma economico-organizzativo. Una PMI con due developer e nessun DevOps dedicato dovrebbe quasi sempre orientarsi su soluzioni managed. Un’azienda con team infrastrutturale strutturato e volumi elevati pu\u00f2 trovare nelle soluzioni open source un risparmio significativo, oltre alla flessibilit\u00e0 di personalizzazione.<\/p>\n

Kong: il leader open source<\/h2>\n

Kong API gateway<\/strong> \u00e8 probabilmente la soluzione open source pi\u00f9 diffusa nel 2021. Costruita sopra Nginx e OpenResty, Kong nasce nel 2015 dall’azienda Mashape, che nel 2017 si rinomina Kong Inc. Il prodotto core \u00e8 scritto in Lua e offre prestazioni eccellenti \u2014 milioni di richieste al secondo su hardware modesto.<\/p>\n

L’architettura di Kong \u00e8 basata su plugin: routing, autenticazione, rate limiting, trasformazione, logging sono tutti plugin caricabili dinamicamente. La community ha sviluppato decine di plugin aggiuntivi, e scriverne di propri in Lua o Go \u00e8 relativamente semplice. La configurazione avviene via API REST o via file YAML dichiarativi (DB-less mode), con supporto nativo a Kubernetes tramite l’Ingress Controller ufficiale.<\/p>\n

Kong esiste in tre edizioni: Kong Gateway (Community Edition)<\/em> open source e gratuita; Kong Enterprise<\/em> con plugin avanzati (RBAC, OAuth 2.0 server, portali developer); Kong Konnect<\/em>, l’offerta SaaS managed lanciata nel 2020. La forza di Kong \u00e8 la maturit\u00e0 della codebase, la community attiva, la documentazione eccellente. Lo svantaggio \u00e8 che il setup self-hosted richiede competenze su PostgreSQL\/Cassandra (o su modalit\u00e0 DB-less) e sull’ecosistema Nginx.<\/p>\n

Tyk: alternativa open source matura<\/h2>\n

Tyk<\/strong> \u00e8 la principale alternativa open source a Kong. Scritto in Go, \u00e8 nato nel 2014 e offre un’architettura monolitica pi\u00f9 semplice da deployare rispetto a Kong: un singolo binario, configurazione via JSON, nessuna dipendenza esterna obbligatoria oltre a Redis per le cache distribuite.<\/p>\n

Le funzionalit\u00e0 sono comparabili a Kong: routing, multiple authentication schemes (JWT, OAuth 2.0, HMAC, basic auth), rate limiting, quotas per utente, transformation, analytics integrate. Tyk include nativamente un developer portal, mentre su Kong \u00e8 una funzionalit\u00e0 della Enterprise Edition. Il dashboard di amministrazione di Tyk \u00e8 considerato pi\u00f9 immediato di quello di Kong, soprattutto per team alle prime armi.<\/p>\n

Tyk \u00e8 una scelta sensata quando si vuole un’unica soluzione integrata (gateway + developer portal + analytics) senza dipendere da Nginx. La community \u00e8 meno ampia di quella di Kong, ma il supporto commerciale \u00e8 disponibile e l’azienda \u00e8 solida.<\/p>\n

\"Team
Tyk: alternativa open source con developer portal nativo<\/figcaption><\/figure>\n

AWS API Gateway, Azure API Management, Google Apigee<\/h2>\n

I tre cloud provider principali offrono servizi managed di API gateway con caratteristiche distintive.<\/p>\n

AWS API Gateway<\/strong> \u00e8 il pi\u00f9 anziano, lanciato nel 2015. Esiste in tre tipologie: REST API (la versione classica, ricca di funzionalit\u00e0 ma pi\u00f9 costosa), HTTP API (pi\u00f9 leggera ed economica, lanciata nel 2020) e WebSocket API. L’integrazione nativa con Lambda permette architetture serverless pure, mentre la connessione a servizi VPC consente di esporre API verso backend tradizionali. Il modello di pricing \u00e8 pay-per-request, vantaggioso per traffici discontinui ma costoso per volumi elevati. La curva di apprendimento \u00e8 ripida \u2014 la console AWS \u00e8 notoriamente complessa \u2014 ma l’ecosistema \u00e8 ineguagliabile.<\/p>\n

Azure API Management<\/strong> \u00e8 il prodotto Microsoft, disponibile in tier diversi (Consumption, Developer, Basic, Standard, Premium) con prezzi mensili fissi (eccetto Consumption pay-per-use). Si integra nativamente con Azure AD per l’autenticazione, con Application Insights per il monitoring, con Azure Functions per il serverless. Include un developer portal personalizzabile e un sistema di “policy” basato su XML per applicare logiche custom. \u00c8 la scelta naturale per organizzazioni gi\u00e0 investite nell’ecosistema Microsoft.<\/p>\n

Apigee gateway<\/strong>, acquisita da Google nel 2016 e integrata in Google Cloud Platform, \u00e8 storicamente il prodotto pi\u00f9 orientato all’enterprise: sviluppato per gestire programmi API mission-critical, offre funzionalit\u00e0 avanzate di monetization (fatturazione delle chiamate API a clienti terzi), analytics di alto livello, machine learning per individuare anomalie nel traffico. Il pricing \u00e8 significativamente superiore agli altri (parte da migliaia di euro al mese), giustificato da feature che PMI raramente usano. Apigee \u00e8 la scelta giusta quando le API sono il prodotto, non un dettaglio implementativo.<\/p>\n

API Gateway vs Service Mesh<\/h2>\n

Una confusione comune nel 2021 riguarda il rapporto tra API gateway e service mesh<\/strong> (Istio, Linkerd, Consul Connect). Entrambi gestiscono traffico di rete, entrambi offrono routing, observability, sicurezza. Eppure rispondono a problemi diversi.<\/p>\n

L’API gateway gestisce il traffico nord-sud<\/em>: dall’esterno (client pubblici, app, sistemi terzi) verso l’interno (i microservizi). Il service mesh gestisce il traffico est-ovest<\/em>: tra microservizi all’interno del cluster. Un gateway tipicamente espone qualche centinaio di endpoint pubblici; un service mesh pu\u00f2 governare migliaia di chiamate inter-servizio al secondo.<\/p>\n

Le due tecnologie sono complementari, non alternative. Un’architettura matura pu\u00f2 prevedere entrambe: un API gateway in front per il traffico pubblico e un service mesh dietro per il traffico interno. Iniziare con il solo gateway \u00e8 normale: il service mesh introduce complessit\u00e0 operativa significativa e ha senso solo quando il numero di microservizi e di chiamate inter-servizio diventa rilevante.<\/p>\n

Casi d’uso pratici per PMI italiane<\/h2>\n

Nelle PMI italiane gli scenari ricorrenti in cui un API gateway porta valore concreto sono cinque.<\/p>\n

Esposizione di API pubbliche.<\/strong> Un’azienda B2B che vuole offrire integrazioni ai propri clienti (gestionale che parla con il sistema cliente, marketplace che espone catalogo a partner) ha bisogno di API documentate, autenticate, monitorate. Il gateway \u00e8 il punto di partenza per costruire un programma API serio.<\/p>\n

Modernizzazione di sistemi legacy.<\/strong> Un ERP on-premise scritto vent’anni fa pu\u00f2 essere “wrappato” da API moderne esposte tramite gateway. Il client esterno parla REST\/JSON al gateway, che traduce e dialoga con il sistema legacy nei suoi protocolli nativi. \u00c8 un pattern di facade che permette di rinnovare l’integrazione senza riscrivere il core.<\/p>\n

Backend for frontend (BFF).<\/strong> Un’app mobile e un sito web hanno bisogno di dati simili ma aggregati in modo diverso. Il gateway pu\u00f2 fornire endpoint specifici per ciascun frontend, aggregando chiamate a microservizi multipli e restituendo solo i campi rilevanti. Il pattern BFF riduce il numero di round-trip dal client e semplifica il codice frontend.<\/p>\n

Multi-tenant SaaS.<\/strong> Una piattaforma SaaS con clienti multipli pu\u00f2 usare il gateway per applicare quote per tenant, rate limiting differenziato per piano commerciale, isolamento dei log per cliente. Funzionalit\u00e0 che sarebbero complesse da implementare a livello applicativo diventano configurazione del gateway.<\/p>\n

Integrazioni con servizi terzi.<\/strong> Un’azienda che orchestra chiamate verso decine di servizi esterni (Stripe, SendGrid, sistemi di shipping) pu\u00f2 usare il gateway come punto di centralizzazione, con retry policy, circuit breaker, log uniformi. Per progetti di integrazione API<\/a> custom questo approccio \u00e8 ormai lo standard.<\/p>\n

Costi indicativi 2021 (free tier vs enterprise)<\/h2>\n

I costi variano enormemente in base a soluzione, volume e modalit\u00e0 di deployment. Diamo un’idea di massima dei valori 2021.<\/p>\n

Open source self-hosted<\/strong>: licenza zero, ma serve hardware\/cloud (per Kong su un cluster Kubernetes minimale parliamo di 100-300 \u20ac\/mese) pi\u00f9 tempo persona per setup e mantenimento (calcolare almeno mezza giornata persona\/mese in regime stabile, di pi\u00f9 nelle prime settimane).<\/p>\n

AWS API Gateway<\/strong>: REST API costa circa 3,50 USD per milione di richieste; HTTP API circa 1,00 USD per milione. Per un servizio con 10 milioni di chiamate al mese parliamo di 10-35 USD, pi\u00f9 i costi di Lambda o backend collegati.<\/p>\n

Azure API Management<\/strong>: tier Developer (per ambienti non produttivi) costa circa 50 \u20ac\/mese; tier Basic parte da 130 \u20ac\/mese; tier Standard intorno ai 600 \u20ac\/mese; tier Premium oltre i 2.500 \u20ac\/mese con SLA del 99,99% e multi-region.<\/p>\n

Kong Enterprise<\/strong>: pricing su richiesta, tipicamente parte da circa 25.000 USD\/anno per deployment medi; Kong Konnect (managed) ha tier Plus a partire da 250 USD\/mese per un singolo control plane.<\/p>\n

Apigee<\/strong>: tier Evaluation gratuito per sviluppo; pricing produzione su richiesta, tipicamente da 25.000 USD\/anno in su, fino a centinaia di migliaia per le edizioni enterprise.<\/p>\n

Una valutazione TCO seria deve includere costi nascosti: tempo persona per gestione, costi di formazione, costi di migrazione futura, eventuali aumenti tariffari del provider.<\/p>\n

Errori frequenti nelle implementazioni<\/h2>\n

Vedere errori ricorrenti aiuta a evitarli. Cinque sono i pi\u00f9 comuni nelle implementazioni che abbiamo osservato sul campo.<\/p>\n

Gateway come monolite.<\/strong> Concentrare nel gateway logica applicativa specifica (validazioni di business, calcoli, trasformazioni complesse) lo trasforma in un nuovo monolite. Il gateway deve restare “thin”: routing, sicurezza, observability, niente pi\u00f9. La logica di business sta nei servizi, non nel gateway.<\/p>\n

Single point of failure non gestito.<\/strong> Se tutto il traffico passa dal gateway e il gateway cade, l’intera piattaforma \u00e8 offline. Cluster ad alta disponibilit\u00e0, health check, deployment multi-region (per servizi critici) sono prerequisiti operativi, non optional.<\/p>\n

Sottovalutazione delle latenze.<\/strong> Ogni hop aggiunge latenza. Un gateway ben tunato aggiunge 1-3 ms; uno mal configurato pu\u00f2 aggiungerne 50-100. Il caching aggressivo e la scelta corretta di plugin sono fondamentali. Profilare le latenze prima di andare in produzione \u00e8 obbligatorio.<\/p>\n

Versioning trascurato.<\/strong> Le API evolvono. Senza una strategia di versioning chiara fin dal giorno uno, ci si ritrova a non poter aggiornare endpoint perch\u00e9 client legacy ne dipendono. URL versioning (\/v1\/<\/code>, \/v2\/<\/code>) o header versioning sono entrambi validi: l’importante \u00e8 scegliere e applicare consistentemente.<\/p>\n

Documentazione assente.<\/strong> Un gateway senza OpenAPI\/Swagger aggiornato \u00e8 un gateway difficile da consumare. Auto-generare la documentazione da specifiche OpenAPI mantenute nel codice, esporre un developer portal, fornire esempi di chiamate \u00e8 ci\u00f2 che separa un’API “tecnicamente disponibile” da un’API “effettivamente usabile”.<\/p>\n

Roadmap di scelta<\/h2>\n

Non esiste l’API gateway “migliore” in assoluto. Esiste quello giusto per il proprio contesto. Una roadmap di scelta in cinque passi pu\u00f2 aiutare a strutturare la decisione.<\/p>\n

Passo 1: definire i requisiti.<\/strong> Volume di traffico atteso (richieste\/secondo medie e di picco), numero di API da gestire, tipologia di client (browser, mobile, partner B2B), requisiti normativi (GDPR, settori regolamentati), SLA target.<\/p>\n

Passo 2: valutare il contesto cloud.<\/strong> L’organizzazione \u00e8 gi\u00e0 su AWS, Azure, GCP, on-premise, multi-cloud? La risposta orienta verso il gateway nativo del provider o verso una soluzione cloud-agnostic.<\/p>\n

Passo 3: stimare i costi.<\/strong> Calcolare il TCO a 3 anni includendo licenze, infrastruttura, tempo persona, formazione, migrazione. Confrontare almeno tre alternative.<\/p>\n

Passo 4: PoC su scenario reale.<\/strong> Mai scegliere senza una proof-of-concept di 2-4 settimane su un caso d’uso reale. Un gateway che funziona bene su slide pu\u00f2 rivelarsi inadeguato su workload specifici.<\/p>\n

Passo 5: definire la strategia di exit.<\/strong> Cosa succede se tra due anni vogliamo cambiare gateway? Quanto costa la migrazione? Tenere il codice di routing e le policy in formato dichiarativo (YAML\/JSON) facilita future migrazioni; logica embedded in plugin proprietari le complica.<\/p>\n

Per architetture enterprise ben progettate consigliamo di valutare anche la sinergia con altre componenti del sistema: web app e PWA<\/a> moderne, soluzioni cloud<\/a> scalabili e gestionali personalizzati<\/a> sono tasselli che insieme al gateway disegnano architetture coerenti.<\/p>\n

Domande frequenti<\/h2>\n

Quando un’azienda dovrebbe iniziare a usare un API gateway?<\/strong> Nel momento in cui ha pi\u00f9 di 3-4 servizi backend che espongono API, oppure quando una singola API \u00e8 consumata da pi\u00f9 tipologie di client (web + mobile + partner). Sotto quella soglia un reverse proxy semplice (Nginx, HAProxy) pu\u00f2 bastare.<\/p>\n

Kong API gateway o AWS API Gateway?<\/strong> Dipende dal contesto. AWS API Gateway \u00e8 la scelta naturale se l’architettura \u00e8 gi\u00e0 serverless su AWS. Kong \u00e8 preferibile per architetture cloud-agnostic, multi-cloud, o quando si vuole evitare il vendor lock-in. Non sono mutuamente esclusivi: ci sono casi in cui hanno senso entrambi.<\/p>\n

Un API gateway sostituisce un Web Application Firewall (WAF)?<\/strong> No. Sebbene molti gateway includano funzionalit\u00e0 di security di base, un WAF dedicato (Cloudflare, AWS WAF, ModSecurity) offre protezione pi\u00f9 approfondita contro OWASP Top 10. In architetture mature il WAF sta davanti al gateway, non al posto.<\/p>\n

\u00c8 possibile mantenere un API gateway interno (private) e uno esterno (public)?<\/strong> S\u00ec, \u00e8 un pattern comune. Il gateway esterno gestisce traffico pubblico con regole di sicurezza stringenti; il gateway interno gestisce traffico tra business unit con policy meno restrittive. Si parla di “two-tier gateway pattern”.<\/p>\n

Service mesh come Istio sostituisce un API gateway?<\/strong> No. Istio gestisce traffico est-ovest tra microservizi, l’API gateway gestisce traffico nord-sud. Sono complementari, non alternativi. Esistono soluzioni che combinano entrambi (Kong Gateway + Kong Mesh, Istio Gateway), ma le due funzioni restano distinte concettualmente.<\/p>\n

Per approfondimenti generali rimandiamo alla voce di API management su Wikipedia<\/a> e al sito ufficiale di Kong<\/a>, che offre tutorial gratuiti e documentazione tecnica di alto livello.<\/p>\n

\n

Hai bisogno di un’architettura API enterprise?<\/h3>\n

Brentasoft sviluppa architetture API custom con API Gateway (Kong, AWS, Azure) per PMI italiane: routing, rate limiting, monitoring, integrazioni multi-sistema.<\/p>\n

Scopri ERP Brenta →<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Confronto API Gateway 2021: Kong API Gateway, Tyk, AWS API Gateway, Azure API Management e Apigee Gateway. Funzionalita, costi, casi d uso PMI.<\/p>\n","protected":false},"author":2,"featured_media":884,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"API Gateway: confronto 2021 (Kong, Apigee, AWS)","_seopress_titles_desc":"Confronto API Gateway 2021: Kong API Gateway, Tyk, AWS API Gateway, Apigee Gateway, Azure API Management. Funzionalita, costi e casi d uso PMI italiane.","_seopress_robots_index":"","footnotes":""},"categories":[9],"tags":[494,559,560,223,557,561,558],"class_list":["post-883","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guide-e-tutorial","tag-api-gateway","tag-apigee","tag-aws-api-gateway","tag-integrazione","tag-kong","tag-mulesoft","tag-tyk"],"_links":{"self":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/883","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/comments?post=883"}],"version-history":[{"count":0,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/883\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media\/884"}],"wp:attachment":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media?parent=883"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/categories?post=883"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/tags?post=883"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}