{"id":3530,"date":"2021-09-03T13:59:00","date_gmt":"2021-09-03T11:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3530"},"modified":"2024-02-02T12:00:17","modified_gmt":"2024-02-02T11:00:17","slug":"come-integrare-lapi-legacy-con-il-proxy-aws-api-gateway","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/come-integrare-lapi-legacy-con-il-proxy-aws-api-gateway\/","title":{"rendered":"Come integrare l’API legacy con il proxy AWS API Gateway"},"content":{"rendered":"\n
L’emergere di moderne applicazioni Web e mobile, basate su microservizi che espongono le API HTTP, ha evidenziato la necessit\u00e0 di integrare, distribuire, decommissionare, limitare e proteggere efficacemente una pletora di API Web eterogenee. Il motivo principale che ha causato l’affermarsi di questa necessit\u00e0 \u00e8 da ricercarsi nella disomogeneit\u00e0 intrinseca delle risorse di backend permesse e promosse dal modello a microservizi: ogni micro servizio che costituisce un’applicazione complessa pu\u00f2 essere sviluppato e distribuito con criteri esclusivi (linguaggio di programmazione, piattaforma di distribuzione, ecc.). Alcuni dei sopra citati criteri possono essere delle SaaS API, ovvero del software completamente fuori dal controllo diretto dell’azienda che sviluppa l’applicazione nel suo complesso. <\/p>\n\n\n\n
Diverse aziende e iniziative open source hanno sviluppato delle soluzioni API gateway<\/strong> al fine di soddisfare i requisiti di cui sopra, per aiutare gli sviluppatori e SysOps a gestire e proteggere le API in modo integrato ed infine per esporre un formato API consistente per tutti i microservizi che compongono l’applicazione.<\/p>\n\n\n\n <\/p>\n\n\n\n Il servizio di Amazon che si fa carico delle necessit\u00e0 appena citate \u00e8 AWS API Gateway<\/strong>, le cui integrazioni con servizi esistenti di AWS e di terze parti sono descritte nell’immagine sopra riportata. Essenzialmente questo servizio agisce da proxy (con la possibilit\u00e0 di modificare e arricchire le richieste in entrata), caching, load balancer e un generale layer di sicurezza generale per tutte le API.<\/p>\n\n\n\n A differenza di molte altre soluzioni, AWS API Gateway \u00e8 completamente gestito e serverless; ci\u00f2 si traduce nell\u2019assenza di manutenzione e ridimensionamento in quanto le API vengono gestite da AWS su pagamento di una tariffa fissa calcolata sul tasso di richiesta (per le API REST ~ 1,5 $ per milione di richieste).<\/p>\n\n\n\n Di seguito verr\u00e0 proposto un approfondimento dell’argomento principale: perch\u00e9 e come utilizzare questo servizio per l’integrazione di API legacy, preceduto da un breve riepilogo sulle integrazioni AWS API Gateway.<\/p>\n\n\n\n Integrazioni API Gateway<\/strong><\/p>\n\n\n\n Nel contesto di API Gateway, un’integrazione API \u00e8 il tipo di azione eseguita dal gateway per rispondere a una data richiesta API. L’integrazione viene invocata dopo la validazione e l’autorizzazione della richiesta (se configurata\/necessaria). AWS API Gateway (API GW da qui in poi) supporta diversi tipi di integrazioni API:<\/p>\n\n\n\n Un caso d’uso molto comune di API gateway nel mondo reale, in cui molte delle integrazioni descritte in precedenza sono effettivamente utilizzate, consiste nella migrazione di un’applicazione legacy da un’infrastruttura monolitica a una moderna applicazione modularizzata basata su microservizi. In questo caso d’uso si avranno tipicamente molte API ancora ospitate sull’infrastruttura monolitica e altre API gi\u00e0 migrate su AWS Lambda (con l’integrazione AWS_PROXY) e\/o AWS ECS (Fargate) esposte tramite un bilanciatore di carico.<\/p>\n\n\n\n API gateway esporr\u00e0 un singolo endpoint che pu\u00f2 essere mappato su un Fully Qualified Domain Name (FQDN) a scelta utilizzando la funzionalit\u00e0 Custom Domain API Gateway.<\/p>\n\n\n\n Proxy di un’API esistente<\/strong><\/p>\n\n\n\n Concentriamoci ora sull’integrazione con la parte monolitica legacy dell’applicazione in fase di migrazione e supponiamo, per semplicit\u00e0, che le API esistenti siano pubblicamente raggiungibili, anche se con qualche sforzo in pi\u00f9 le API esistenti esposte privatamente sia on-prem che su AWS possono anche essere proxate (https:\/\/docs.aws.amazon.com\/apigateway\/latest\/developerguide\/http-api-develop-integrations-private.html<\/a>). Nell’esempio fornito qui utilizzeremo la regione AWS Irlanda (eu-west-1).<\/p>\n\n\n\n Iniziamo creando una nuova API nella console web AWS API GW: apri il tuo account AWS, vai al servizio API Gateway (https:\/\/eu-west-1.console.aws.amazon.com\/apigateway\/main\/apis?region=eu-west-1) e creiamo una nuova API, ci viene presentata la seguente procedura guidata:<\/p>\n\n\n\n I vari tipi di API che puoi selezionare hanno funzionalit\u00e0 diverse: le Websocket API sono utilizzate per applicazioni full-duplex in tempo reale, sicuramente non il nostro caso, mentre le API HTTP e REST sono entrambe scelte legittime. Le API HTTP, tuttavia, implementano solo un sottoinsieme delle funzionalit\u00e0 disponibili con le API REST. Ad esempio non sono implementate l\u2019autenticazione tramite il servizio Cognito, l\u2019autenticazione Iam, le integrazioni generiche di servizi AWS e le trasformazioni delle richieste tramite velocity template. <\/p>\n\n\n\n In questo esempio, per essere il pi\u00f9 generici possibile, useremo le API REST ma si tenga presente che le richieste API HTTP costano meno del 30% delle richieste API REST, quindi sono spesso la scelta pi\u00f9 conveniente.<\/p>\n\n\n\n Quindi facciamo clic su Crea su API REST, quindi scegli Nuova API e imposta nome e descrizione.<\/p>\n\n\n\n Il tipo di endpoint definisce dove sono ubicati gli endpoint: un endpoint edge crea una CDN (distribuzione Cloudfront) completamente gestita per distribuire gli endpoint in tutte le regioni AWS, quindi pi\u00f9 vicini ai clienti. Il rovescio della medaglia \u00e8 che diverse operazioni (es. associazioni di domini personalizzati, implementazioni) sono pi\u00f9 lente, mentre il prezzo \u00e8 lo stesso. In questo caso scegliamo l\u2019endpoint Regionale.<\/p>\n\n\n\n Fare clic su Crea API per finalizzare la procedura guidata di creazione.<\/p>\n\n\n\n Ora \u00e8 finalmente il momento di integrare la nostra API legacy. La cosa pi\u00f9 semplice che puoi fare \u00e8 configurare un semplice proxy utilizzando l’integrazione HTTP_PROXY. In questo esempio, l’integrazione HTTP_PROXY ha come target un\u2019API simulata di Petstore e distribuita da AWS su http:\/\/petstore-demo-endpoint.execute-api.com<\/a>.<\/p>\n\n\n\n Una volta creata la risorsa, questa pu\u00f2 essere visualizzata nella barra di sinistra come \/{proxy+}. Puoi selezionarla e in Azioni Risorsa si pu\u00f2 creare prima un Metodo di tipo ANY con le seguenti impostazioni:<\/p>\n\n\n\n<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n