Nei primi 3 articoli di questa serie, ho provato a definire "la cornice" di una tematica complessa:
- Api "economy": quale impatto sulla Comunicazione Tecnica?
- Documentare le API? Le risposte nascono dalle domande...
- Documentare le API: per quale audience?
Ora provo ad analizzare "il quadro", che è composto da diverse aree in relazione tra di loro, come in un quadro di Mondrian:
Le gRPC API, sviluppate da Google, sono servizi web simili alle RPC API basate su RPC. gRPC definisce i messaggi non in formato XML o JSON ma attraverso un buffer, specificato attraverso un file con estensione .proto. Il buffer.proto consente di definire la struttura dei dati e il modo in cui serializzare i dati che devono essere consumati dal server ricevente. Il formato "protobuffer" è considerato più leggero efficiente rispetto ad XML.
GraphQL
Le GraphQL API sono servizi web sviluppati da Facebook che consentono un'interazione dinamica basata su un unico endpoint. La query GraphQL recupera solo i dati necessari, consentendo richieste e risposte veloci.
Async API
AsyncAPI è uno standard open source mirato alle architetture basate su eventi (Event Driven Architecture). Simile alla specifica OpenAPI, consente di definire un'interfaccia comune per le interfacce EDA e consente una gestione multicanale. Quindi la stessa specifica può essere utilizzata per un API basata su MQTT o per una API Kafka.
AsyncAPI si basa su due concetti:
- i messaggi guidano la maggior parte delle interazioni API
- questi messaggi descrivono azioni o eventi.
In sostanza, AsyncAPI crede che tutto possa essere rappresentato come un sistema di messaggi, con un'intestazione e un payload facoltativi o non richiesti. In questa visione, AsyncAPI cerca di abilitare la definizione di API utilizzando definizioni basate sul canale indipendenti dal protocollo.
Librerie di API
Le "API basate su libreria", si riferiscono a librerie di codice (ad esempio, file JAR) che gli sviluppatori aggiungono direttamente ai loro progetti per fornire funzionalità aggiuntive tramite classi e metodi (nel caso di linguaggi ad oggetti come Java, .NET stack, C++) o altre funzioni che possono essere chiamate localmente. Con le API della libreria nativa, le funzioni sono incorporate localmente all'interno del codice per potenziare le operazioni realizzate dall'applicazione. Questo tipo di API sono strutturalmente diverse rispetto alle Web API che abbiamo elencato in precedenza.
Un esempio? OpenSSL API, cioè la più importante libreria crittografica open source.
----------------------------------------------
ABBIAMO FINITO? Ovviamente no.
Ci sono altri tipi di API che potremmo dover documentare? Certo.
Allora diciamo che sono abbastanza confidente di avervi fornito "una mappa di base" per iniziare ad orientarvi rispetto alle caratteristiche generali delle API che attualmente coprono, ragionevolmente, il 90% dei casi che potreste dover gestire.
A presto.
Nessun commento:
Posta un commento