Cos'è un'API? In inglese per favore.

Prima di imparare lo sviluppo del software, l'API sembrava una specie di birra.

Oggi uso il termine così spesso che di recente ho provato a ordinare un'API in un bar.

La risposta del barista è stata di lanciare un 404: risorsa non trovata.

Incontro molte persone, sia che lavorano nella tecnologia che altrove, che hanno un'idea piuttosto vaga o errata di cosa significhi questo termine abbastanza comune.

Tecnicamente, API sta per Application Programming Interface . Prima o poi, la maggior parte delle grandi aziende ha creato API per i propri clienti o per uso interno.

Ma come spieghi l'API in un inglese semplice? E c'è un significato più ampio di quello utilizzato nello sviluppo e nel business? Per prima cosa, torniamo indietro e guardiamo come funziona il web stesso.

WWW e server remoti

Quando penso al Web, immagino una grande rete di server connessi .

Ogni pagina su Internet è archiviata da qualche parte su un server remoto. Dopo tutto, un server remoto non è così mistico: è solo una parte di un computer remoto ottimizzato per elaborare le richieste.

Per mettere le cose in prospettiva, puoi avviare un server sul tuo laptop in grado di servire un intero sito Web al Web (infatti, un server locale è ciò che gli ingegneri utilizzano per sviluppare siti Web prima di rilasciarli al pubblico).

Quando digiti www.facebook.com nel tuo browser, viene inviata una richiesta al server remoto di Facebook. Una volta che il tuo browser riceve la risposta, interpreta il codice e visualizza la pagina.

Per il browser, noto anche come client , il server di Facebook è un'API. Ciò significa che ogni volta che visiti una pagina sul Web, interagisci con l'API di un server remoto.

Un'API non è la stessa del server remoto, piuttosto è la parte del server che riceve le richieste e invia le risposte .

API come un modo per servire i tuoi clienti

Probabilmente hai sentito parlare di aziende che impacchettano API come prodotti. Ad esempio, Weather Underground vende l'accesso alla sua API per i dati meteorologici.

Scenario di esempio: il sito web della tua piccola impresa ha un modulo utilizzato per iscrivere i clienti agli appuntamenti. Vuoi dare ai tuoi clienti la possibilità di creare automaticamente un evento del calendario di Google con i dettagli per quell'appuntamento.

Utilizzo dell'API: l'idea è di far parlare il server del tuo sito web direttamente al server di Google con una richiesta per creare un evento con i dettagli forniti. Il tuo server riceverà quindi la risposta di Google, la elaborerà e invierà informazioni pertinenti al browser, come un messaggio di conferma all'utente.

In alternativa, il tuo browser può spesso inviare una richiesta API direttamente al server di Google bypassando il tuo server.

In che modo l'API di Google Calendar è diversa dall'API di qualsiasi altro server remoto là fuori?

In termini tecnici , la differenza è il formato della richiesta e della risposta.

Per eseguire il rendering dell'intera pagina Web, il browser si aspetta una risposta in HTML, che contiene codice di presentazione, mentre la chiamata API di Google Calendar restituirebbe semplicemente i dati, probabilmente in un formato come JSON .

Se il server del tuo sito web sta effettuando la richiesta API, allora il server del tuo sito web è il client (simile al tuo browser che è il client quando lo usi per navigare in un sito web).

Dal punto di vista degli utenti, le API consentono loro di completare l'azione senza lasciare il tuo sito web.

La maggior parte dei siti Web moderni utilizza almeno alcune API di terze parti.

Molti problemi hanno già una soluzione di terze parti, sotto forma di libreria o servizio. Spesso è solo più facile e più affidabile utilizzare una soluzione esistente.

Non è raro che i team di sviluppo suddividano la loro applicazione in più server che dialogano tra loro tramite API. I server che eseguono funzioni di supporto per il server delle applicazioni principale sono comunemente denominati microservizi .

Per riassumere, quando un'azienda offre un'API ai propri clienti, significa semplicemente che ha creato una serie di URL dedicati che restituiscono risposte di dati puri, il che significa che le risposte non conterranno il tipo di sovraccarico di presentazione che ci si aspetterebbe da un interfaccia utente grafica come un sito web .

Puoi fare queste richieste con il tuo browser? Spesso sì. Poiché la trasmissione HTTP effettiva avviene in testo, il browser farà sempre del suo meglio per visualizzare la risposta.

Ad esempio, puoi accedere all'API di GitHub direttamente con il tuo browser senza nemmeno bisogno di un token di accesso. Ecco la risposta JSON che ottieni quando visiti il ​​percorso API di un utente GitHub nel tuo browser (//api.github.com/users/petrgazarov):

{ "login": "petrgazarov", "id": 5581195, "avatar_url": "//avatars.githubusercontent.com/u/5581195?v=3", "gravatar_id": "", "url": "//api.github.com/users/petrgazarov", "html_url": "//github.com/petrgazarov", "followers_url": "//api.github.com/users/petrgazarov/followers", "following_url": "//api.github.com/users/petrgazarov/following{/other_user}", "gists_url": "//api.github.com/users/petrgazarov/gists{/gist_id}", "starred_url": "//api.github.com/users/petrgazarov/starred{/owner}{/repo}", "subscriptions_url": "//api.github.com/users/petrgazarov/subscriptions", "organizations_url": "//api.github.com/users/petrgazarov/orgs", "repos_url": "//api.github.com/users/petrgazarov/repos", "events_url": "//api.github.com/users/petrgazarov/events{/privacy}", "received_events_url": "//api.github.com/users/petrgazarov/received_events", "type": "User", "site_admin": false, "name": "Petr Gazarov", "company": "PolicyGenius", "blog": "//petrgazarov.com/", "location": "NYC", "email": "[email protected]", "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 aver visualizzato correttamente una risposta JSON. Una risposta JSON come questa è pronta per essere utilizzata nel codice. È facile estrarre dati da questo testo. Quindi puoi fare quello che vuoi con i dati.

A sta per "Applicazione"

Per concludere, introduciamo un altro paio di esempi di API.

"Applicazione" può riferirsi a molte cose. Eccone alcuni nel contesto dell'API:

  1. Un software con una funzione distinta.
  2. L'intero server, l'intera app o solo una piccola parte di un'app.

Fondamentalmente qualsiasi pezzo di software che può essere distintamente separato dal suo ambiente, può essere una "A" nell'API e probabilmente avrà anche una sorta di API.

Supponiamo che tu stia utilizzando una libreria di terze parti nel tuo codice. Una volta incorporata nel codice, una libreria diventa parte della tua app complessiva. Essendo un software distinto, la libreria avrebbe probabilmente un'API che le consente di interagire con il resto del codice.

Ecco un altro esempio: in Object Oriented Design , il codice è organizzato in oggetti. La tua applicazione potrebbe avere centinaia di oggetti definiti che possono interagire tra loro.

Ogni oggetto dispone di un'API, un insieme di proprietà e metodi pubblici che utilizza per interagire con altri oggetti nell'applicazione.

An object may also have inner logic that is private, meaning that it’shiddenfrom the outside scope (and not an API).

From what we have covered, I hope you take away the broader meaning of API as well as the more common uses of the term today.

Interesting Resources (stuff that I left out but is still very cool):

A great youtube video on DNS (Domain Name System)

HTTP protocol basics

An Awesome Khan Academy video on Object Oriented Design Principles