Articolo originale: What is an API? In English, please.
Prima di studiare sviluppo software, API mi sembrava un qualche tipo di birra.
Oggi uso il termine così spesso che ho effettivamente tentato di ordinare un API al bar.
La risposta del barista è stata "404: risorsa non trovata".
Conosco molte persone, sia che lavorano nel campo tech che altrove, che hanno un'idea piuttosto vaga o non corretta di cosa voglia realmente dire questo termine.
Tecnicamente, API sta per Application Programming Interface (intefaccia di programmazione di un'applicazione). Prima o poi, tutte le grandi società hanno realizzato delle API per i loro clienti o per utilizzo interno.
Ma come spiegare cosa vuol dire API in soldoni? E c'è un significato più ampio che viene usato in altri settori? Prima di tutto, facciamo un passo indietro e partiamo da come funziona il web.
WWW e server remoti
Quando penso al Web, mi immagino una larga rete di server connessi tra loro.
Tutte le pagine internet vengono memorizzate da qualche parte su dei server remoti. Un server remoto non è un oggetto così misterioso dopotutto - è solo una parte di un computer localizzato in remoto che è ottimizzato per processare richieste.
Per mettere le cose in prospettiva, puoi allestire un server sul tuo laptop in modo da servire un intero sito web (infatti, un server locale è ciò che gli ingegneri usano per sviluppare i siti web prima di rilasciarli al pubblico).
Quando scrivi sul tuo browser www.facebook.com, viene inviata una richiesta al server remoto di Facebook. Quando il tuo browser riceve la risposta, interpreta il codice e ti permette di visualizzare la pagina.
Per il browser, anche detto client, il server di Facebook è un'API. Questo vuol dire che ogni volta che visita una pagina web, interagisci con le API di qualche server remoto.
Un'API non è il server remoto - piuttosto è una parte del sever che riceve delle richieste e invia delle risposte.
Le API sono un modo per servire i clienti
Probabilmente, hai sentito parlare di società che hanno delle API come prodotti. Ad esempio, Weather Underground vende l'accesso all'API per i dati meteo.
Situazione esempio: il tuo piccolo sito web ha un modulo per prendere appuntamenti con i clienti e vuoi dare la possibilità ai tuoi clienti di creare automaticamente un evento con i dettagli dell'appuntamento su Google Calendar.
Uso dell'API: l'idea è che il server del tuo sito web comunichi direttamente con il server di Google con la richiesta di creare un evento con determinati dettagli. Il tuo server dovrà ricevere la risposta di Google, processarla e rimandare al browser le informazioni rilevanti, come un messaggio di conferma per l'utente.
Alternativamente, il tuo browser può inviare una richiesta API direttamente al server di Google, bypassando il tuo server.
In cosa differisce l'API di Google Calendar rispetto all'API di un qualsiasi altro server remoto?
In termini tecnici, la differenza sta nel formato della richiesta e nella risposta.
Per renderizzare l'intera pagina web, il tuo browser si aspetta una risposta in HTML, che contiene del codice di presentazione, mentre la chiamata dell'API di Google Chrome restituisce dei dati - probabilmente in un formato come JSON.
Se il tuo sito web sta facendo delle richieste API, allora il server del tuo sito è il client (proprio come il tuo browser è il client quando lo usi per navigare in un sito).
Dalle prospettiva degli utenti, le API permettono loro di completare delle azioni senza lasciare il tuo sito.
La maggior parte dei siti web moderni utilizza delle API di terze parti.
Molti problemi hanno già una soluzione fornita da terze parti, sia in forma di libreria che di servizio, e spesso è più semplice e affidabile adottare la soluzione già esistente.
Non è raro per i team di sviluppatori dividere le proprie applicazioni in più server che comunicano tra di loro via API. I server che effettuano funzioni di aiuto per i server delle applicazioni principali vengono comunemente detti microservizi.
Ricapitolando, quando una società offre un'API ai propri clienti, vuol dire che ha realizzato un set di URL dedicati che restituiscono una risposta in formato di dati - in altre parole, la risposta non contiene il tipo di intestazione di presentazione che ci si aspetta in una interfaccia utente grafica come un sito web.
Puoi fare queste richieste con il tuo browser? Spesso, la risposta è sì. Dato che l'effettiva trasmissione HTTP avviene come testo, il tuo browser farà sempre del suo meglio per visualizzare la risposta.
Ad esempio, puoi accedere all'API di GitHub direttamente dal tuo browser senza nemmeno bisogno di un token d'accesso. Ecco la risposta JSON che ottieni visitando una route API di un utente di GitHub nel tuo browser (https://api.github.com/users/petrgazarov):
{
"login": "petrgazarov",
"id": 5581195,
"avatar_url": "https://avatars.githubusercontent.com/u/5581195?v=3",
"gravatar_id": "",
"url": "https://api.github.com/users/petrgazarov",
"html_url": "https://github.com/petrgazarov",
"followers_url": "https://api.github.com/users/petrgazarov/followers",
"following_url": "https://api.github.com/users/petrgazarov/following{/other_user}",
"gists_url": "https://api.github.com/users/petrgazarov/gists{/gist_id}",
"starred_url": "https://api.github.com/users/petrgazarov/starred{/owner}{/repo}",
"subscriptions_url": "https://api.github.com/users/petrgazarov/subscriptions",
"organizations_url": "https://api.github.com/users/petrgazarov/orgs",
"repos_url": "https://api.github.com/users/petrgazarov/repos",
"events_url": "https://api.github.com/users/petrgazarov/events{/privacy}",
"received_events_url": "https://api.github.com/users/petrgazarov/received_events",
"type": "User",
"site_admin": false,
"name": "Petr Gazarov",
"company": "PolicyGenius",
"blog": "http://petrgazarov.com/",
"location": "NYC",
"email": "petrgazarov@gmail.com",
"hireable": null,
"bio": null,
"public_repos": 23,
"public_gists": 0,
"followers": 7,
"following": 14,
"created_at": "2013-10-01T00:33:23Z",
"updated_at": "2016-08-02T05:44:01Z"
}Il browser sembra essersi comportato bene mostrando una risposta JSON. Una risposta JSON come questa è pronta per essere utilizzata nel tuo codice. È facile estrarre dati da questo testo e puoi fare ciò che desideri con questi dati.
A sta per “Applicazione”
Per concludere, facciamo un altro paio di esempi sulle API.
"Applicazione", in questo contesto, può riferirsi a molte cose, tra cui:
- Una parte di un software con una funzione particolare.
- L'intero server, l'intera app o sono una parte di un'app.
Praticamente, qualsiasi parte di un software che può essere separata distintamente dal suo ambiente può essere la "A" di API e avrà probabilmente un'API di qualche tipo.
Supponiamo che stai usando una libreria di terze parti nel tuo codice. Una volta incorporata nel tuo codice, la libreria diventa una parte della tua app. Essendo un componente distinto del software, la libreria avrà con tutta probabilità un'API che le permette di interagire con il resto del codice.
Ecco un altro esempio: nella progettazione orientata agli oggetti, il codice è organizzato in oggetti. La tua applicazione può avere centinaia di oggetti definiti che interagiscono tra loro.
Ogni oggetto ha un'API - un set di metodi pubblici e proprietà che utilizza per interagire con altri oggetti all'interno dell'applicazione.
Un oggetto può anche avere una logica interna privata, cioè nascosta dallo scope esterno (e non un'API).
Spero che leggendo quest'articolo tu abbia compreso il significato più ampio di API, così come l'uso più comune che si fa del termine.
Risorse (cose interessanti di cui non ho parlato):
Un ottimo video sul DNS (Domain Name System)
Un fantastico video su Khan Academy sui principi della programmazione orientata agli oggetti