Cos’è un API Endpoint?

Le API e gli endpoint sono sempre stati un argomento di discussione tra gli sviluppatori frontend e backend. Per sviluppare applicazioni e servizi utili e sostenibili, le API sono state medium potenti.

Le API facilitano la trasmissione dei dati tra vari artefatti software per risolvere i problemi dei clienti. Quasi tutti i prodotti moderni basati sul web offrono API per interagire e integrare i servizi in modo diretto in qualsiasi progetto.

Per stare al passo con i concorrenti e fornire ai vostri utenti un’esperienza fluida attraverso diverse piattaforme, dovete padroneggiare il gioco delle API.

Questa guida vi aiuterà a capire cos’è un API endpoint, come consumare un’API disponibile al pubblico e in che modo proteggere e monitorare i vostri API endpoint.

Capire gli Endpoint delle API

“API” è l’abbreviazione di “Application Programming Interface”. È essenzialmente un insieme di regole che permettono ad un’applicazione di condividere i suoi dati con altre applicazioni. In parole semplici, un’API vi permetterà di “condividere cose” tra la vostra applicazione e un’applicazione di terze parti.

Un API endpoint è un luogo digitale esposto tramite l’API dal quale l’API riceve le richieste e invia le risposte. Ogni endpoint è un URL (Uniform Resource Locator) che fornisce la posizione di una risorsa sul server dell’API.

Per capire lo scopo e l’utilizzo delle API, cerchiamo prima di capire come funzionano.

Come Funzionano le API

Per far sì che due applicazioni software comunichino su Internet, un’applicazione (indicata come client) invia una richiesta agli API endpoint dell’altra applicazione (indicata come server). A seconda delle capacità dell’API, il client potrebbe richiedere una risorsa da un database o chiedere al server di eseguire qualche azione nel suo ambiente e restituire i risultati.

Alla ricezione del risultato trasmesso dal client, l’API (o il server) esegue l’operazione richiesta e invia il risultato dell’operazione al client sotto forma di risposta. Questa risposta può anche includere una qualsiasi risorsa richiesta dal client.

Ci possono essere diversi tipi di API, tra cui REST, SOAP e GraphQL. Funzionano tutte in modo diverso, ma il loro scopo è sempre lo stesso: facilitare la comunicazione tra entità basate sul web. In questa guida parleremo principalmente delle API REST poiché sono tra le API più popolari a livello globale.

Qual è la Differenza Tra un’API e un Endpoint?

Questo ci porta alla successiva e più frequente domanda: Qual è la differenza tra un’API e un endpoint?

Un’API è un insieme di protocolli e strumenti per facilitare l’interazione tra due applicazioni. Un endpoint è un posto sull’API dove avviene lo scambio. Gli endpoint sono URI (Uniform Resource Identifiers) su un’API a cui un’applicazione può accedere.

Tutte le API hanno endpoint. Senza un endpoint, sarebbe impossibile interagire con un’API.

Come Funzionano gli Endpoint con le API?

Per comprendere meglio le API e gli endpoint, facciamo un piccolo esempio.

Prendete l’API di Cat Facts. Questa API fornisce fatti casuali sui gatti. Tuttavia, elenca vari endpoint utilizzando i quali è possibile richiedere informazioni categorizzate. Sono disponibili tre endpoint:

• /fact: Restituisce un singolo fatto casuale sui gatti.
• /facts: Restituisce un elenco di fatti casuali sui gatti.
• /breeds: Restituisce un elenco di razze di gatti.

Per fare una richiesta a questa API e recuperare un fatto sui gatti, dovete aggiungere l’endpoint corretto (che è /fact) all’URL di base dell’API (che è https://catfact.ninja/). Questo vi darà il seguente URL dell’endpoint: https://catfact.ninja/fact

Se inviate una richiesta GET all’URL qui sopra, riceverete un risultato simile a questo:

{
    "fact": "Spanish-Jewish folklore recounts that Adamu2019s first wife, Lilith, became a black vampire cat, sucking the blood from sleeping babies. This may be the root of the superstition that a cat will smother a sleeping baby or suck out the childu2019s breath.",
    "length": 245
}

Ora, non avreste potuto ottenere questi dati accedendo ad un altro endpoint, come /breeds. In questo modo gli endpoint permettono di interagire e organizzare le risorse fornite da un’API: ogni endpoint è specifico per una particolare porzione di dati.

Perché gli Endpoint delle API Sono Importanti?

Il trasferimento dei dati e la condivisione delle risorse sono tra le fondamenta di Internet. Ogni giorno, un numero sempre maggiore di processi e applicazioni vengono aggiunti alla rete globale, una condivisione che aggiunge valore alla rete.

Senza le API, niente di tutto questo sarebbe possibile. Le API forniscono un potente mezzo di comunicazione e interazione tra le applicazioni basate sul web.

Gli endpoint delle API, a loro volta, permettono di stabilire l’esatta posizione delle risorse nell’API. Aiutano gli sviluppatori di API ad organizzare le risorse disponibili e a controllare anche l’accesso dei consumatori. Quindi le prestazioni e la produttività delle applicazioni che consumano API dipendono direttamente dal design e dalle prestazioni degli endpoint delle API.

Lavorare con gli Endpoint delle API Esistenti

Nella maggior parte dei casi, vi verrà richiesto di consumare API pre-costruite. Prima dovrete però capire come localizzare gli endpoint e trovare la vostra strada con le varie regole di versioning utilizzate nel settore. Questa sezione vi accompagnerà nell’analisi.

Localizzare gli Endpoint di un’API

Localizzare gli endpoint di un’API è semplice se avete accesso alla documentazione dell’API. A volte, la documentazione potrebbe fornire un elenco di endpoint con brevi descrizioni accanto a ciascuno di essi. In altri casi (come Swagger), la documentazione potrebbe essere più completa e complessa e potreste anche testare gli endpoint direttamente dalla pagina della documentazione.

In ogni caso, è nel vostro interesse dedicare un po’ di tempo a capire lo scopo di ogni endpoint prima di iniziare ad usarlo. Questo può aiutarvi ad evitare la maggior parte degli errori e ad aumentare la vostra efficienza.

Versioning degli Endpoint delle API

Come la maggior parte degli altri artefatti software, anche le API hanno delle versioni. Il versioning aiuta ad osservare e analizzare l’API mentre progredisce nel corso dello sviluppo. Avere accesso alle vecchie versioni può aiutarvi anche a tornare alle versioni precedenti e stabili in caso di aggiornamenti difettosi. Ecco alcuni dei modi in cui vengono stabilite le versioni degli endpoint delle API.

Percorso URI

Uno dei modi più utilizzati per stabilire la versione degli endpoint delle API è quello di includere un numero di versione nel percorso dell’URI. Ecco come potrebbe apparire:

http://example.com/api/1/resourcename

Questo approccio può essere visto come un modo per stabilire globalmente le versioni degli endpoint delle API. Se utilizzate un sottodominio per la vostra API, come ad esempio:

http://api.example.com/resourcename

… potete anche aggiungere un indicatore di versione nel vostro sottodominio, come questo:

http://api-v2.example.com/resourcename

Come potete vedere, questo approccio modifica il percorso URI dell’API, quindi ogni versione si comporta come una risorsa indipendente. Questo significa che potete accedere simultaneamente alle due versioni dell’API come necessario e anche metterle in cache in modo indipendente per un accesso più rapido.

Quando si include un numero di versione nel percorso URI (e non nel sottodominio), ecco un formato ordinato che permette di includere un maggior numero di informazioni:

MAJOR.MINOR.PATCH

Per esempio, questo è il modo in cui l’API interna del nostro esempio precedente verrebbe versionata:

http://example.com/api/1.2.3/resourcename

Ora analizziamo questi nuovi termini di versione e cerchiamo di capire a cosa servono:

• MAJOR: quando fate cambiamenti incompatibili o di rottura delle API
• MINOR: quando aggiungete funzionalità compatibili con le versioni precedenti
• PATCH: per correzioni di bug retrocompatibili

La versione MAJOR qui è la versione utilizzata nell’API pubblica. Questo numero viene di solito aggiornato quando viene fatto un cambiamento importante o una modifica all’API. Internamente, un tale cambiamento indica che è stata creata una nuova istanza o risorsa API.

Le versioni MINOR e PATCH sono utilizzate internamente per gli aggiornamenti di retrocompatibilità. Di solito vengono aggiornate quando viene introdotta una nuova funzionalità o quando vengono fatti dei cambiamenti minori alla stessa risorsa API. Il numero PATCH viene aggiornato specificamente per correzioni di bug o aggiornamenti per la risoluzione di problemi.

• Benefici:
  • Accesso concorrente a più versioni.
  • La denominazione degli URL segue una convenzione semplice e standard, quindi gli endpoint dell’API sono altamente accessibili.
• Limitazioni:
  • Nel caso di modifiche, questo approccio porta allo sviluppo di una nuova risorsa API. Questo può aggiungere un peso significativo al vostro codebase.

Parametri di Query

Un’alternativa per il versioning di una REST API è quella di mettere il numero di versione nei parametri di query del suo URL. Questo permette all’ambiente server di accedere al numero di versione richiesto come con qualsiasi altro parametro di query e utilizzarlo per reindirizzare il flusso di controllo nell’applicazione. Non avete bisogno di creare una nuova risorsa API, perché la vostra risorsa API esistente può leggere il numero di versione e agire come richiesto.

Questo è l’aspetto che avrebbe l’URL dell’esempio precedente se versionato utilizzando i parametri della query:

http://example.com/api/resourcename?version=1

• Benefici:
  • Molto facile da implementare nel codice.
  • Si può rapidamente passare alla versione più recente.
• Limitazioni:
  • I parametri possono essere più complessi da utilizzare per indirizzare le richieste alla versione corretta rispetto al versioning del percorso URI.

Header Personalizzati

È possibile anche fare versioning di API REST fornendo intestazioni personalizzate con il numero di versione come attributo. La differenza più significativa tra questo metodo e i due descritti in precedenza è che questo non ingombra l’URL dell’endpoint con informazioni sulla versione.

Ecco come apparirebbe l’esempio di prima secondo questo approccio:

curl -H "Accepts-version: 2.0"

http://example.com/api/resourcename

• Benefici:
  • L’URL non è ingombra di informazioni sulla versione.
  • I clienti possono digitare manualmente gli URL degli endpoint dell’API e scegliere tra le versioni tramite le intestazioni mentre inviano rapidamente la richiesta.
• Limitazioni:
  • È necessario impostare manualmente le intestazioni personalizzate ogni volta che si fa una richiesta.

Negoziazione dei Contenuti

La negoziazione dei contenuti permette agli sviluppatori di API di modificare una singola rappresentazione della risorsa invece dell’intera API. Questo dà loro un controllo più granulare sul versioning. Proprio come nel caso precedente, anche questo metodo rimuove il disordine dagli URL delle API.

Ecco come apparirebbe il nostro esempio di prima quando viene modificato tramite la negoziazione dei contenuti:

curl -H "Accept: application/vnd.kb.api+json; version=2"

http://example.com/api/resourcename

Tuttavia, gli endpoint versionati seguendo questo approccio sono più difficili da raggiungere rispetto a quelli che seguono l’approccio URI. Inoltre, l’utilizzo delle intestazioni HTTP con i media type rende difficile testare l’API in un browser. E se l’intestazione del contenuto è opzionale, può causare confusione sulla versione che i client riceveranno di default.

Diciamo che per la vostra API avete rilasciato una v2 e deprecato la vecchia v1. Se un client non specifica la versione nella richiesta, riceverà la risorsa v2, che potrebbe interrompere la funzionalità per problemi di compatibilità non considerati. Questo è il motivo per cui la negoziazione dei contenuti di solito non è raccomandata come mezzo di versioning delle API

• Benefici:
  • È possibile fare il versioning di una singola risorsa se necessario.
  • Crea un’impronta di codice più piccola.
  • Non richiede modifiche alle regole di routing (URL).
• Limitazioni:
  • Le intestazioni HTTP con i media type rendono difficile testare ed esplorare gli endpoint in un browser.
  • La mancanza dell’intestazione del contenuto potrebbe interrompere la funzionalità del client.

Esempio di un API Endpoint

Per capire meglio le API e gli endpoint, mostreremo un esempio utilizzando l’API di Twitter. Questa API espone dati su tweet, messaggi diretti, utenti e altro dalla piattaforma di social media. Offre vari endpoint per eseguire diverse operazioni sui dati.

Per esempio, potete utilizzare l’endpoint tweet lookup (https://api.twitter.com/2/tweets/{id}) per recuperare il contenuto di un tweet specifico utilizzando il suo identificatore univoco. Potete anche utilizzare l’API di Twitter per trasmettere i tweet pubblici in tempo reale alla vostra applicazione web per tenere informati i vostri utenti su un particolare argomento.

A questo scopo, l’API di Twitter offre un endpoint di flusso filtrato (https://api.twitter.com/2/tweets/search/stream). Hanno anche creato un indice esteso di altri endpoint.

Come Sono Protetti gli Endpoint delle API?

Ora che avete capito come appare e funziona l’endpoint di un’API, è fondamentale sapere come proteggerlo. Senza adeguate misure di sicurezza, un API endpoint può essere una grossa falla nell’armatura della vostra app, che potenzialmente può portare a violazioni di dati e risorse.

Ecco alcuni suggerimenti per rendere sicuro l’accesso agli endpoint delle vostre API.

Hashing delle Password One-Way

Quando costruite risorse web, vi imbatterete spesso nelle password per autenticare le entità. Anche se le password aiutano a proteggere i dati delle applicazioni dei vostri utenti, avete bisogno di proteggere anche la memorizzazione delle password per renderle un mezzo di autenticazione davvero efficace.

In generale, non dovreste mai memorizzare le password come testo semplice. In caso di violazione della sicurezza, se un attore malevolo mette le mani sulla tabella delle coppie di stringhe di nome utente e password, tutti gli account utente saranno compromessi.

Un modo per impedirlo è quello di crittografarle prima di memorizzarle. Ci sono due metodi di crittografia – simmetrico e asimmetrico.

Nella crittografia simmetrica, potete utilizzare la stessa chiave di crittografia per bloccare e sbloccare il contenuto. Tuttavia, questa soluzione non è consigliata per le password perché gli hacker persistenti e sofisticati possono romperle facilmente.

Il modo raccomandato di memorizzare le password è quello di utilizzare la crittografia unidirezionale o “asimmetrica”. Invece di utilizzare una singola chiave di crittografia, per codificare i dati viene utilizzata una funzione matematica.

La versione criptata viene memorizzata nel database in modo che nessuno, compresi gli amministratori del server, possa decifrare le password e visualizzarle. Per l’autenticazione degli utenti, la password inserita viene eseguita attraverso la stessa funzione matematica e i risultati vengono confrontati per verificare che la password inserita sia corretta.

HTTPS

Supponiamo che gli endpoint della vostra API siano progettati per permettere ai consumatori di comunicare con i vostri servizi. In questo caso, non implementando HTTPS (o un altro protocollo di sicurezza simile) li metterete a forte rischio.

Le connessioni API di solito scambiano dati sensibili come password, chiavi segrete e informazioni di pagamento. Questi dati possono essere facilmente rubati da un attacco machine-in-the-middle o attraverso metodi di sniffing dei pacchetti.

È il motivo per cui dovreste fare in modo di scegliere sempre HTTPS quando è disponibile. Se le vostre applicazioni utilizzano il protocollo HTTP, dovreste considerare fortemente la migrazione a HTTPS. Non importa quanto sia insignificante la connessione, può sempre portare ad una perdita.

Dovreste anche considerare la possibilità di scegliere un certificato TLS o SSL per migliorare ancora di più la sicurezza della vostra API.

Limitazione della Quota

Nella maggior parte dei casi, è una buona idea impostare un limite sul numero di volte che la vostra API può essere utilizzata in un minuto. Questo vi aiuta a controllare un eventuale uso improprio delle risorse e a portare un modello di prezzi gestito in base al vostro traffico di utenti.

Tuttavia, una ragione importante per implementare la limitazione della quota è quella di evitare un utilizzo automatizzato delle risorse eccessivo, che di solito si verifica grazie ai bot, che possono inviare centinaia o migliaia di richieste simultanee ogni secondo. Il rate limiting può anche aiutarvi a bloccare qualsiasi attacco DDoS lanciato da questi bot.

La maggior parte dei framework di sviluppo web fornisce middleware di limitazione della quota già pronti che sono facili da configurare. Anche se il vostro framework non ha un middleware, potete ottenerne uno tramite una libreria di terze parti e configurarlo abbastanza velocemente.

Oltre a fare attenzione ai bot, è anche una buona abitudine limitare il numero consentito di richieste o di dati recuperati ad un numero ragionevole. Questo vi aiuta a prevenire l’utilizzo eccessivo involontario delle risorse che può essere innescato da errori manuali come i cicli infiniti. Vi aiuta anche a fornire ai vostri utenti una disponibilità uniforme – un picco nell’utilizzo di un utente non influenza l’esperienza degli altri utenti.

Misure di Autenticazione dell’API

Ogni volta che costruite un’API rivolta al pubblico, dovete implementare misure di autenticazione per prevenire l’uso improprio e l’abuso dei vostri servizi. Una buona opzione è il sistema OAuth2.

OAuth2 divide il vostro account in risorse e vi permette di fornire un accesso controllato ai portatori di token di autenticazione. Potete impostare questi token in modo che scadano dopo un determinato periodo di tempo – diciamo 24 ore – allo scadere del quale saranno rinnovati. Questo assicura che, anche se il vostro token dovesse trapelare, la finestra di utilizzo limitata ridurrà l’impatto della perdita.

Una parte essenziale della sicurezza delle API è l’utilizzo delle chiavi API per autenticare le richieste. Potete impostare le chiavi API in modo da limitare le chiamate alla vostra API e ridurre le possibilità di attacchi DoS. Se offrite un servizio API a pagamento, potete utilizzare le chiavi API per fornire un accesso basato sui piani che ogni utente ha acquistato.

Dovreste anche valutare lìipotesi di dotare gli endpoint interni dei dipendenti di autenticazione a più fattori, software antivirus e aggiornamenti automatici delle app. Queste semplici misure faranno molto per assicurare che non ci siano riduzioni della qualità dei servizi che offrite.

Convalida dell’Input

Anche se sembra una cosa ovvia, quando si costruisce una qualsiasi applicazione software, un numero sorprendente di API non riesce ad implementarla correttamente. La convalida dell’input si riferisce non solo al controllo che i dati in entrata siano in un formato corretto, ma riguarda anche l’evitare sorprese.

Uno degli esempi più semplici, ma più frequenti, è l’SQL injection. Non tener conto di questo, eseguendo la query sbagliata, può spazzare via il vostro intero database. Assicuratevi di convalidare i dati di input per il formato corretto e rimuovete i caratteri che possono essere indizio di intenti malevoli.

Un’altra cosa a cui prestare attenzione è la dimensione della richiesta. Nel caso delle richieste POST, tentare di accettare e analizzare un input estremamente grande farà solo esplodere la vostra API. Dovreste sempre fare prima la convalida della dimensione di una richiesta POST e restituire un codice di errore appropriato e un messaggio al client se opportuno.

Filtro degli Indirizzi IP

Se offrite servizi B2B e i vostri clienti usano la vostra API da diverse località a livello globale, potrebbe essere opportuno aggiungere un ulteriore livello di sicurezza ai vostri sistemi, limitando gli indirizzi IP che accedono alla vostra API in base alla posizione.

Dovreste aggiungere i dati delle nuove location e dei nuovi clienti al vostro elenco di “sedi consentite”. Anche se questo può aggiungere attrito al processo di accesso dei vostri clienti, sarà molto utile per migliorare la sicurezza e, di conseguenza, la qualità della loro esperienza.

Per ridurre ulteriormente i rischi per la sicurezza, sarebbe bene anche limitare i permessi e l’accesso dei clienti al minimo necessario per le operazioni standard. Allo stesso modo, limitate il vostro accesso HTTP per garantire che i client mal configurati non ricevano altro che le specifiche API e il codice di accesso. Assicuratevi che la vostra API rifiuti queste richieste con un codice di risposta 405.

Una gran parte dei cyberattacchi nel mondo proviene da un numero limitato di paesi. Un’altra best practice è quella di bloccare completamente l’accesso alle vostre risorse da questi luoghi se lì non avete clienti.

Inoltre, se rilevate un attacco, iniziate subito a bloccare le richieste GET/POST provenienti dalla regione dell’attaccante. La capacità di limitare le richieste HTTP basate sulle località dei clienti è una delle soluzioni più veloci per contrastare un attacco informatico in corso.

XDR (Rilevamento e Risposta Estesi)

La maggior parte delle organizzazioni utilizza strumenti di sicurezza tradizionali come i firewall e le tecniche di protezione/rilevamento delle intrusioni. Anche se sono strumenti rudimentali per qualsiasi sistema di sicurezza, non sono progettati esplicitamente per le API.

Una nuova tecnologia chiamata XDR fornisce una soluzione migliore e più olistica alla protezione dei vostri ambienti IT, compresi i vostri API endpoint. XDR fornisce ai team di sicurezza avvisi in tempo reale su comportamenti dannosi, il che permette loro di indagare rapidamente sugli attacchi.

Ecco in che modo XDT protegge gli API endpoint:

• Monitoraggio HTTPS: XDR può gestire i certificati di sicurezza dei vostri endpoint e ispezionare anche le comunicazioni HTTP. Quando rileva un’anomalia, può terminare rapidamente la connessione o intraprendere altre azioni automatiche.
• Monitoraggio delle chiamate API: XDR può tenere traccia del numero di chiamate API effettuate dai vostri clienti e notificare i vostri team di sicurezza quando rileva tendenze sospette anche all’interno dei limiti di velocità impostati.
• JSON web token (JWT): JWT è un metodo standard utilizzato per rappresentare in modo sicuro l’identità di un utente quando si comunica su una rete. XDR può permettere di identificare gli utenti tramite JWT sulle vostre reti senza dover trasmettere le credenziali. Questo vi permette di identificare gli account utente nel vostro traffico API e di analizzare il loro comportamento alla ricerca di anomalie.
• Filtro degli indirizzi IP: XDR si integra bene con i database di threat intelligence e controlla le richieste in entrata alla ricerca di indirizzi IP o origini legittime.
• Convalida dell’input: Anche se non avete implementato adeguate misure di sanitizzazione dell’input nel vostro servizio, le soluzioni XDR possono analizzare automaticamente SQL o altre query sensibili sul database per rilevare gli attacchi di iniezione, fermarli sul nascere e notificarli ai team di sicurezza.

Routine di Manutenzione

Potete impostare alcune routine generali di manutenzione per migliorare la sicurezza delle vostre API. Eccone alcune:

• Pulite i dati: Eliminate i dati ridondanti di utenti e dipendenti dai vostri servizi. La pulizia dei dati di routine non è solo una buona pratica, ma permette anche di diminuire le possibilità di perdita o corruzione accidentale dei dati.
• Eseguite aggiornamenti regolari: Ricordatevi di aggiornare regolarmente il vostro stack tecnologico e le certificazioni dei servizi. Dovreste implementare patch di routine per i vostri servizi endpoint e tutte le vostre licenze dovrebbero riflettere gli ultimi standard di regolamentazione e conformità.
• Rivedete le misure di sicurezza: Tenete aggiornati i vostri piani di sicurezza e di recupero. Dovrebbero riflettere le ultime modifiche o aggiunte alla vostra infrastruttura di rete il più frequentemente possibile. Se aggiungete regolarmente nuove risorse mobili, IoT o altre risorse on-premise, questa pratica è ancora più critica.

Monitoraggio degli Endpoint delle API

Ora che avete capito come costruire, consumare e proteggere gli endpoint delle API, un’altra cosa importante è il monitoraggio. Il monitoraggio è un concetto delicatocritico, applicato in tutte le dinamiche dell’ingegneria del software per analizzare e rafforzare la crescita dei prodotti tecnologici.

Suggerimenti, Trucchi e Best Practice

Nel caso delle API, il monitoraggio può aiutarvi a proteggere e ottimizzare i vostri endpoint per ottenere prestazioni superiori e migliorare l’affidabilità. La sezione successiva vi illustrerà alcune delle best practice da seguire durante la strumentazione e il monitoraggio degli API endpoint.

1. Convalidare l’Operatività Funzionale

Generalmente, i team tendono a monitorare la disponibilità o l’operatività delle API e lo considerano uno standard per misurare la qualità del servizio delle API. Tuttavia, misurare solo la disponibilità generale delle API non è sufficiente per i vari tipi di transazioni di scambio dati che avvengono tramite le API. È necessario monitorare la disponibilità e le prestazioni di tutti i verbi (Create, Read, Update, Delete, ecc.) singolarmente per assicurarvi che siano tutti operativi.

Per farlo, potete implementare strumenti di monitoraggio sintetico con monitor API multi-step. Questo vi aiuterà a migliorare la disponibilità delle API e dei dati contemporaneamente. Allo stesso tempo, bisogna ricordare che il monitoraggio sintetico utilizza un insieme limitato e predefinito di chiamate API per i test. Quindi il traffico reale del mondo reale può differire dal set di input nel monitoraggio sintetico.

2. Ricordatevi di Monitorare le Dipendenze delle API

Non tutte le API sono costruite in modo indipendente. Spesso avrete bisogno di consumare API di terze parti mentre costruite le vostre. E anche se potete strumentare il vostro codice fino ai suoi livelli più profondi, potrete facilmente dimenticare di monitorare il comportamento delle API di terze parti.

Quindi dovrete tracciare anche le risposte delle API di terze parti. Nella nostra esperienza, le dipendenze difettose hanno creato un gran trambusto ogni volta che non siamo riusciti ad analizzarle in modo indipendente.

3. Implementate Test Automatizzati nel Monitoraggio delle API

Se avete impostato una pipeline CI/CD ben definita, probabilmente conoscete già l’importanza dell’automazione. Quindi è meglio se potete impostare test automatizzati per i vostri API endpoint insieme al monitoraggio. Dovreste considerare di aggiungere un ulteriore passo nelle vostre pipeline CI/CD per eseguire test automatici sui vostri endpoint prima di un rilascio. Anche se oggi questa è diventata la norma, dovreste controllare se l’avete implementato o meno.

4. Scegliete uno Strumento con una Funzionalità di Allerta Affidabile

Con la varietà di strumenti disponibili sul mercato attuale, può essere difficile trovare quello giusto per il vostro caso d’uso specifico. Per rendere la vostra ricerca più facile, ecco una regola da ricordare: cercate sempre capacità di allerta affidabili. Se lo strumento selezionato non vi avvisa adeguatamente dei problemi in arrivo, dovrete costantemente perdere tempo per intervenire e controllare se si sono verificati degli eventi. L’automazione in questo campo fa davvero molto nell’aumentare la produttività del vostro team.

5. Date Priorità agli Strumenti che Sono Direttamente Integrabili nella Vostra Pipeline CI/CD

Dovreste pensare di integrare il monitoraggio in ogni fase della vostra pipeline CI/CD per analizzare l’efficienza dei vostri processi DevOps. Per questo, dovete selezionare attentamente gli strumenti che offrono tale funzionalità.

Per verificare che il vostro strumento ne dispone, cercate nell’elenco delle integrazioni di terze parti fornite. Se il vostro server CI, come Jenkins o GitHub, è supportato, siete a posto!

6. Non Scendete Mai a Compromessi sulla Privacy delle API

Alcuni strumenti di monitoraggio delle API sfruttano piattaforme SaaS di terze parti che richiedono ai clienti di aprire certe porte sui loro firewall per monitorare API interne altrimenti irraggiungibili. Queste, tuttavia, rappresentano un grande rischio per la sicurezza. Chiunque sia a conoscenza di queste porte può usarle per ottenere un accesso non autorizzato ai vostri sistemi.

Ecco perché è imperativo scegliere una buona soluzione di monitoraggio delle API che prenda in considerazione il design delle vostre API e vi permetta di monitorare ogni endpoint, sia interno che esterno, in modo sicuro. I migliori strumenti per questo scopo sono quelli che possono accedere privatamente alle vostre API interne senza lasciare spazio ad intrusioni.

7. Monitorate 24/7

Non monitorare le API letteralmente tutto il tempo può costarvi una fortuna enorme. Qualsiasi servizio può andare giù in qualsiasi momento. E se il vostro servizio di monitoraggio in quel momento è oscurato, dovrete aspettare che il servizio torni attivo per sapere che c’è stata un’interruzione. E in quella finestra potete perdere affari preziosi.

Suggeriamo, quindi, di impostare dei monitor ad alta frequenza che vengano eseguiti almeno cinque volte all’ora per i test funzionali e una volta all’ora per la sicurezza e il monitoraggio OAuth.

8. Preferite il Monitoraggio Esterno a Quello Interno

Spesso i problemi non si verificano uniformemente all’interno e all’esterno. I vostri utenti potrebbero affrontare un problema che non potete riprodurre all’interno dei firewall del vostro sistema. In questo caso, non importa se le vostre metriche interne funzionano correttamente; l’utente non può accedere al vostro prodotto, quindi ogni metrica operativa non è di alcuna utilità.

Per evitare queste situazioni, preferite sempre una configurazione di monitoraggio esterno a quella interna. Per risolvere i problemi dei vostri utenti, dovete guardare le vostre API dalla prospettiva dell’utente.

9. Monitorate Tutte le Risorse

Nella costruzione del servizio o dell’applicazione dietro la vostra API, potreste progettare alcuni componenti di base o complessi. Anche se può essere allettante saltare il monitoraggio dei componenti essenziali, non è mai una best practice. Molte volte, un errore apparentemente banale in un componente semplice e non importante può interrompere un’applicazione estesa.

Se non avete occhi ovunque, sarete costretti a sprecare ore alla ricerca del componente che ha causato il problema, solo per scoprire che quel piccolo pezzo che consideravate troppo innocente per essere difettoso è in realtà il vero colpevole.

10. Analizzate Tutti i Parametri di Risposta

Controllare solo che il codice di stato restituisca 200 non è sufficiente. Per le risposte generiche, la maggior parte degli sviluppatori usa i codici di stato HTTP di base, come 200 per il successo e 500 per l’errore del server. Tuttavia, il successo o l’errore possono avere diverse forme e tracciare ogni istanza di questi è essenziale per stabilire come stanno funzionando le vostre API.

Dovreste anche cercare cambiamenti nella dimensione dei contenuti restituiti dalle API. Se la risposta usuale ha una dimensione di 500 kb, ma avete ricevuto solo 100 kb o meno, probabilmente avete incontrato qualche tipo di errore.

Strumenti di Monitoraggio delle API

Per implementare le best practice menzionate sopra, dovete iniziare con una soluzione di monitoraggio delle API. In framework come WordPress, ci sono plugin pronti all’uso per il monitoraggio delle API, ma dovrete cercare una soluzione più completa nel caso di applicazioni puramente programmate.

Nella prossima sezione, presenteremo una breve serie di strumenti di monitoraggio delle API di tendenza per aiutarvi ad iniziare con il minimo sforzo (e costo).

Uptrends

Uptrends offre il monitoraggio di applicazioni web, API, server e molto altro. Ha una vasta base di clienti con oltre 25.000 organizzazioni piccole e grandi, compresi alcuni nomi importanti come Microsoft, Vimeo e Volkswagen.

Una caratteristica sorprendente di questo fornitore è il test basato sul browser. Utilizza browser reali e unici per eseguire applicazioni e siti web e cattura metriche dettagliate sulle prestazioni.

Ma i tempi di risposta e le metriche non sono le uniche caratteristiche del servizio. Con Uptrends, avrete anche un rapporto dettagliato sulle prestazioni di ciascuna delle vostre risorse che vi consente di individuare tutti i possibili colli di bottiglia nel vostro sistema. Per ogni errore, Uptrends fa uno screenshot e ve lo invia in modo che possiate sperimentare l’errore così come si è verificato.

Dotcom-Monitor

Dotcom-Monitor permettere agli utenti di configurare un dispositivo di monitoraggio multi-task utilizzando un job HTTP o HTTPS. Questo vi permette di monitorare la disponibilità, le risposte corrette e le prestazioni delle API.

Gli agenti Dotcom-Monitor replicano una o più richieste del client per verificare se i dati possono essere adeguatamente scambiati tra l’API e i client. Quando uno degli agenti rileva un errore, controlla l’errore con un elenco di filtri preimpostati. Se l’errore non viene filtrato, l’agente attiva un allarme.

Lo strumento vi permette di impostare programmi di allarme personalizzati e alternative di escalation. Potete esportare i rapporti sugli errori in vari formati, come CSV, PDF, TXT e altri. I rapporti sugli errori di Dotcom-Monitor mostrano diversi indicatori preziosi, come i tempi di inattività, i tempi di risposta e le prestazioni medie per località.

Dotcom-Monitor è tra le soluzioni di monitoraggio API più convenienti e i piani partono da 1,99 dollari al mese. Se la vostra è un’organizzazione in crescita con un budget limitato, Dotcom-Monitor potrebbe essere la soluzione di monitoraggio API giusta per voi.

Graphite

Graphite è un sistema di monitoraggio API open-source che permette di catturare metriche dalle API facendo in modo che il servizio spinga i dati nel componente Graphites Carbon. Graphite poi memorizza questi dati in un database per trarne degli approfondimenti.

Graphite è popolare tra i suoi utenti per la semplicità della procedura di installazione, che comprende un’installazione automatica e uno script di configurazione dello stack, conosciuto come Synthesize.

Un’altra caratteristica sorprendente offerta da Graphite è la capacità di memorizzare eventi arbitrari. Questi eventi sono generalmente legati a metriche di serie temporali. All’interno di Graphite, è anche possibile aggiungere e tracciare le implementazioni di applicazioni o infrastrutture, cosa che permette al vostro team di sviluppo di trovare le cause di problemi e strozzature più velocemente e di ottenere un migliore contesto sugli eventi e sulle anomalie che portano a comportamenti inattesi.

Sematext

Sematext è una soluzione popolare tra i team DevOps, grazie alla suite di strumenti di monitoraggio che offre. Il monitoraggio delle API è parte del servizio di monitoraggio sintetico, conosciuto come Sematext Synthetics.

Sematext fornisce un complesso sistema di monitoraggio API e di allerta che potete personalizzare per lavorare in base a diversi errori e metriche. È possibile configurare lo strumento per effettuare un doppio o triplo controllo prima di inviare un avviso. Può aiutarvi ad eliminare i falsi positivi dai vostri avvisi e avere informazioni più accurate e pertinenti.

Grazie al potente monitor HTTP di Sematext, avete anche una funzione completa di monitoraggio dal browser. Vi permette di generare metriche sulle prestazioni web basate su interazioni utente pre-scritte con le vostre applicazioni web. Questo significa che potrete andare oltre i soliti standard dei test di monitoraggio dei tempi di caricamento delle pagine, dei tempi di contentful paint, ecc. e dare uno sguardo più approfondito alle interazioni dettagliate dell’utente emulate, come il flusso di autenticazione in-app, l’esecuzione delle query di ricerca o l’aggiunta o la rimozione di articoli da un carrello. Sematext fornisce diverse interazioni utente di questo tipo.

BlazeMeter

Blazemeter è una soluzione premier di test e monitoraggio end-to-end per applicazioni moderne. Lo strumento vi dà la completa libertà di scegliere i framework di test open-source e di analizzarli utilizzando semplici dashboard. Offre anche una perfetta integrazione con Apache JMeter, che è tra i migliori strumenti di misurazione delle prestazioni per applicazioni web complesse.

Come la maggior parte delle soluzioni di monitoraggio API, BlazeMeter dispone anche di funzioni fondamentali come i test funzionali (chiamati “scenari”), che potete configurare utilizzando un’interfaccia grafica interattiva. BlazeMeter ha esposto un DSL (Domain Specific Language) tramite il suo strumento di test dedicato Taurus che permette agli sviluppatori di scrivere test generici. Potete poi eseguire questi test su JMeter e altri popolari strumenti open source.

Dato il design pesante, BlazeMeter ha un prezzo più alto. Se la vostra applicazione ha più di 5.000 utenti concorrenti, dovreste prepararvi a sborsare più di 600 dollari al mese. Potete comunque optare per piani a costo fisso basati sull’effettivo utilizzo.

Se il vostro prodotto è nella linea di Pfizer, Adobe, NFL, Atlassian e così via, BlazeMeter è la soluzione di monitoraggio API perfetta per voi.

Questa è una raccolta piuttosto concisa di strumenti di monitoraggio delle API, e ci sono molte altre ottime soluzioni in giro. Date un’occhiata alla raccolta dettagliata di strumenti di monitoraggio delle API di Geekflare e alla guida completa all’acquisto di strumenti di monitoraggio delle API di Sematext prima di fare la vostra scelta!

Riepilogo

Le API sono la spina dorsale della moderna macchina informatica. La maggior parte dei prodotti nel mercato del software sono dotati di un’API per offrire una perfetta integrazione con entità di terze parti. Per fornire un’esperienza utente fluida e fidelizzare i vostri clienti, dovete valutare l’opportunità di costruire e fornire un’API con il vostro prodotto software… il che significa che dovete conoscere le API a fondo.

Questa guida ha lo scopo di aiutarvi ad entrare in questo settore introducendovi ai concetti che sono alla base della tecnologia, le best practice e gli strumenti di monitoraggio API disponibili sul mercato. Ci auguriamo che ora abbiate una migliore comprensione di come le risorse web comunicano tra loro.

Tuttavia, nonostante tutto ciò che abbiamo detto, abbiamo appena scalfito la superficie per quanto riguarda ciò che le API e gli API endpoint possono realizzare. Continua a leggere, a testare e a contattare la comunità di sviluppatori per allargare le vostre conoscenze e abilità con gli API endpoint.