Non solo Microservizi: API, Prodotti e Piattaforme

...non solo Microservizi: API, Prodotti e
Piattaforme!...
Marzo 2021
STEFANO FAGO

Cosa sono le API?
API è l'acronimo di Application Programming Interface, cioè un
intermediario software che consente a due applicazioni di dialogare tra
loro. Un'API è un insieme di funzioni che consente di creare applicazioni che
accedono alle funzionalità o ai dati di un'altra applicazione o servizio.

API Oggi...
API è una chiave d’accesso ad un
universo di concetti, strumenti,
architetture ed in generale un Ecosistema
che raccoglie sforzi ed iniziative sempre
più avanzate!

Internet Companies & API
Il Bezos Mandate è considerato la chiave del successo di Amazon!
E’ stato innescato dall'aumento dei costi dei team all'interno di Amazon (mancanza
di modi coerenti e ben gestiti di scambiare dati e capacità tra loro) e dal conseguente
rallentamento delle pianificazioni di business di Bezos.
Il Bezos Mandate ci ricorda dei concetti cardine:
 Connubio tra Business & IT
 Esposizione di Dati e Funzionalità
 Fondarsi sulla comunicazione tramite interfacce e standardizzare le interazioni dei dati
 Essere agnostici dal punto di visto delle Tecnologie usate
 Progettare per “l’Esterno” come Paradigma
https://www.cio.com/article/3218667/have-you-had-your-bezos-moment-what-you-can-learn-fr
om-amazon.html

API & Business
<< ...Le API sono passate dall’iniziale stato di tecnica di sviluppo ad un driver del
modello di business. Le risorse principali di un'organizzazione possono essere
riutilizzate, condivise, e monetizzate tramite API che possono estendere la portata
dei servizi esistenti o fornire nuovi flussi di entrate. Le API dovrebbero essere gestite
come un prodotto, costruito su una tecnica complessa improntata ad includere sistemi
e dati legacy e di terze parti… >>
[ Deloitte Consulting ]

Definizione di Prodotto
Cos'è un prodotto?
• etichettato
• confezionato
• facile da usare
• documentato
• supportato da un business

Time-To-Market, Prodotto e MVP
Un prodotto per essere considerato efficace
deve posizionarsi opportunamente sul mercato
e questo significa considerarne le evoluzioni.
La rapidità delle odierne evoluzioni di mercato
porta alla visione di Minimum Viable Product.
MVP è una versione di un prodotto con
caratteristiche appena sufficienti per
essere utilizzabile dai primi clienti che possono
quindi fornire feedback per lo sviluppo futuro
del prodotto. Concentrarsi sul rilascio di un
MVP significa che gli sviluppatori
potenzialmente evitano il lavoro lungo e non
necessario.

API as Product e VPI
Le API che divengono prodotti portano al
concetto di VPI: Value Proposition Interface
La Value Proposition è la proposta di
valore che un’azienda fa al mercato,
espressa in termini di vantaggi percepiti,
tangibili o meno, che i consumatori possono
ottenere dall’acquisto della soluzione
proposta sul mercato.
Le API non sono più orientate
all’applicativo ma vengono progettate
insieme al business per offrire un
prodotto che esprima la Value Proposition
aziendale.
API Product Management : https://www.youtube.com/watch?v=G0xASUzunaQ

API & API Economy
API Economy: Interazioni di mercato create con alla base una connessione API
API Economy si riferisce, dunque, al modo in cui le API possono positivamente influire
sulla redditività di un'azienda, consentendo di scalare rapidamente grazie all’accesso a
dati e servizi di terze parti o trasformare i propri servizi e dati in una
piattaforma che attrae partner su cui costruire nuovi servizi e che porta nuovi
clienti.

Macro e Micro Economy
Nell’ambito API Economy si parla di Macro-Economy riferendosi alle
transazione tra Aziende mentre si parla di Micro-Economy nel caso di
interazioni interne ad una data azienda tramite API. E’ possibile distinguere
tre tipologie di API in base al ruolo che giocano all’interno o all’esterno
dell’ecosistema aziendale.
Partner
API
Private
API
Public
API

API: Internal vs External
http://dret.net/lectures/oreilly-sa-ca-2019/

API Economy & Market Place
L’idea dell’API Economy si basa sui fattori di business che le API possono supportare sia
internamente all’azienda che nel rapporto con clienti finali e partner.
Il concetto di Market Place è collegto a quello di API Economy: l’offerta di valore
aggiunto di un’azienda prende forma in un’offerta differenziata e componibile di
funzionalità acquisibili separatamente

Monetizzazione delle API
<< ...la monetizzazione delle API è il processo attraverso il quale le aziende creano entrate
dalle loro API... sono la pietra angolare di quella che è ampiamente considerata come la
prossima iterazione dello sviluppo aziendale, dove avere API ben sviluppate stabilisce e
mantiene relazioni in un'economia digitale… >>
[ https://www.redhat.com/en/topics/api/what-is-api-monetization ]
[ https://www.rdegges.com/2020/the-only-type-of-api-services-ill-use/ ]

API Platform
Un provider di API è un'organizzazione che espone dati e/o funzionalità tramite un servizio
consumabile a livello di codice con una o più Application Programming Interface. Questa
organizzazione è più di un fornitore e diventata una piattaforma quando le sue API:
 Consentono l'accesso alla value-proposition fondamentale dell'organizzazione
 Sono scalabili sia tecnicamente che sul business
 Consentono ai consumatori di creare valore condiviso
 Sono determinanti per garantire la posizione dell'organizzazione come leader di mercato
 Sono viste dal top management come critiche per l'azienda
https://www.apiscene.io/lifecycle/federated-apis-across-ecosystems/

API Management
API REGISTRY
...un inventario delle API di
un'organizzazione che
consente ai consumatori di
interrogare sulle
caratteristiche delle API
disponibili. Il registry aiuterà
anche un'organizzazione
a gestire il ciclo di vita di una
API, catalogando le versioni
supportate e
la loro promozione o il ritiro
da l'inventario delle API
dell'organizzazione…

API Management API GATEWAY
...è il componente
responsabile dell'esposizione
e dell'organizzazione
delle API ai diversi
consumatori. Lo API
Gateway copre le seguenti
aree fondamentali:

Pubblicazione

Sicurezza

Standardizzazione

Controllo dell’Erogazione

Logging & Data Capture

API Management
DEVELOPER PORTAL
...Il Developer Portal fornisce
l'interfaccia umana alle API
di un'organizzazione,
fornisce un'esperienza
utente di qualità (sia
all’interno che per le terze
parti), strumenti e risorse
utili per la creazione di
applicazioni che utilizzano le
API. Inoltre, il portale
fornisce le strutture agli
sviluppatori per gestire il
loro coinvolgimento con
l'organizzazione
(documentazione, notifiche,
metriche)...

Developer Experience
Lo Sviluppatore diventa principale consumatore di API: è per questo motivo che si parla di DX (Developer
Experience)
https://css-tricks.com/what-is-developer-experience-dx/

API Management (Books)

https://www.amazon.it/Continuous-API-Management-Decisions-Landscape/dp/1492043559

https://www.amazon.it/Enterprise-Management-Luis-Augusto-Weir/dp/1787284433

https://www.amazon.it/API-Management-Architects-Developing-Organization-ebook/dp/B06XRTNZNN

API vs Microservices
La recente proposizione dell’architettura a Microservizi può portare all’identificazione delle
API con i Microservizi: questo però non corrisponde alla realtà e può essere
controproducente.
Un microservizio nasce da
un approccio architetturale
che separa porzioni o interi
monoliti applicativi in
servizi di ridotte
dimensioni e auto-
contenuti
Un’API è un contratto che
fornisce la guida verso un
Consumatore di quelle API
al fine di interagire con il
Servizio sottostante.

API vs Microservices
L’obiettivo di un’API non è mostrare le
capacità tecniche del microservizio ma
esporre il suo valore aggiunto ed il
migliore contratto per interfacciarsi con
i clienti di cui deve soddisfare le richieste.
UI
Layer
Orchest.
Layer
Atom.
Services
Layer

API, Gateway, BFF

https://samnewman.io/patterns/architectural/bff/

https://www.quora.com/What-is-backend-for-frontend-pattern

https://www.slideshare.net/GiulioRoggero/come-i-microservizi-favoriscono-il-la
voro-dei-feature-teams

API, BFF, GraphQL

https://speakerdeck.com/timakin/go-backends-for-frontends-with-
graphql-and-grpc

https://medium.com/tech-tajawal/backend-for-frontend-using-gra
phql-under-microservices-5b63bbfcd7d9

https://www.infoq.com/presentations/graphql-bff/

Good fit for complex
systems

Fetching data with a single
API call

No over- and under-
fetching problems

Tailoring requests to your
needs

Validation and type
checking out-of-the-box. ...

Auto-generating API
documentation.

API evolution without
versioning.

Code-sharing.

API, Gateway, Service Mesh
https://betterprogramming.pub/the-roles-of-service
-mesh-and-api-gateways-in-microservice-architect
ure-f6e7dfd61043

API,Gateway,Micro Gateway,Service Mesh

Microservice Design Canvas
Questo Canvas è uno strumento che
aiuta a catturare gli attributi iniziali più
importanti di un servizio prima di crearlo.
Il Canvas ha un approccio sintetico che si
presta a riportare le relazioni tra
l'interfaccia e implementazione del
servizio stesso.
https://apiacademy.co/2017/08/the-micro
service-design-canvas/
https://solusoftsl.github.io/microservices-
design-canvas-editor/

API, Microservices,
Modellazione
Cosa significa Micro? Qual è la corretta dimensione di un servizio? Come la dimensione e, quindi, le funzionalità possibili
condizionano la modellazione di una API?

API, Microservices: Books

https://www.oreilly.com/library/view/securing-microservice-apis/9781492027140/

https://www.amazon.it/Microservice-Architecture-Aligning-Principles-Practices/dp/1491956259

https://www.amazon.it/Monolith-Microservices-Evolutionary-Patterns-Transform/dp/1492047848/

API Ciclo di vita
La definizione di un ciclo di vita delle API segue la stessa visione di un prodotto portando
ad un’evoluzione continua al fine di adeguare e accrescere il marketplace e la value
proposition aziendale
DEFINE OPERATE DEPRECATE DISMISS
LIFECYCLE
OPERATIONS
BUSINESS

HTTP Support: Deprecation
La dismissione di una API dev’essere preceduta da un periodo in cui la stessa viene notificata agli
utilizzatori come Deprecated. L’azione di Deprecation è attuabile:
• su canali email, rss (syndication), chat per la notifica ad operatori umani
• grazie ad apposito HTTP Header in termini di REST API
Esempi:
Deprecato nel passato: Deprecation: Sun, 11 Nov 2018 23:59:59 GMT
Deprecato nel futuro: Deprecation: Sun, 20 Oct 2022 23:59:59 GMT
Definitivamente deprecato: Deprecation: true

HTTP Support: Deprecation
Lo HTTP Header della risposta Deprecation consente a un server di comunicare ad un client che
la risorsa nel contesto del messaggio è o sarà deprecata.
[ https://greenbytes.de/tech/webdav/draft-ietf-httpapi-deprecation-header-01.html ]
L’ambito della deprecation è definito dall’API:
∙ Lo Header dedicato può apparire ovunque o solo su una specifica risorsa
∙ Possono essere fornite ulteriori informazioni con lo header Link
Deprecato con informazioni aggiuntive:
Deprecation: Sun, 11 Nov 2018 23:59:59 GMT
Link: <https://developer.example.com/deprecation>; rel="deprecation"; type="text/
html"

HTTP Support: Sunsetting
Il fornitore di risorse quando desidera comunicare all'applicazione client che si prevede che una
risorsa obsoleta non risponda da un momento specifico in avanti, è possibile usare lo HTTP
Header Sunset [ https://tools.ietf.org/html/rfc8594 ]
The timestamp fornito nello Header Sunset deve essere successivo o lo stesso di quello presente
nello Header Deprecation.
Deprecation: Sun, 11 Nov 2018 23:59:59 GMT
Sunset: Wed, 11 Nov 2020 23:59:59 GMT
Prima che lo Header Sunset appaia per la prima volta è possibile che per la risorsa venga
pubblicata la politica di dismissione utilizzando un Header di tipo Link verso informazioni
specifiche:
Link: <http://example.net/sunset>;rel="sunset";type="text/html"

HTTP Support: Gestione degli Errori
In passato, i codici di stato erano sufficienti ad esprimere
la condizione di una data invocazione.
Le evoluzioni delle API hanno reso necessario avere una
semantica più ricca. La conseguenza è stata il proliferare
di soluzioni e formati per rappresentare le condizioni di
errore nei vari ecosistemi di API delle Internet
Companies.

I differenti approcci utilizzati hanno
creato difficoltà nello sviluppo di API e
la crescente necessità di avere uno
standard di riferimento

La specifica Problem Details for HTTP APIs [ https://tools.ietf.org/html/rfc7807 ] si pone
come standard capace di accogliere le differenti esigenze di gestione degli errori nell’ambito
delle API
• Flessibilità di formato grazie al supporto di differenti MIME Type nell’ambito della content
negotiation HTTP
• Supporto ad informazioni aggiuntive
• Estendibilità delle informazioni ospitate
• Supporto ad errori multipli sulla stessa risposta
• Costruito su alcune considerazioni di sicurezza

La specifica supporta principalmente due tipologie di Content Type previsti come standard
IANA:
• application/problem+json
• application/problem+xml
Il formato prevede I seguenti campi:
• Type: (obbligatorio) un URI che identifica il tipo di errore. Il caricamento dell'URI in un browser
dovrebbe portare alla documentazione dell'errore, ma non è strettamente necessario. Questo
campo può essere utilizzato per riconoscere le classi di errore
• Title: un breve riassunto human-readable dell'errore.Iclient devono usare il Type come metodo
principale per riconoscere i tipi di errore
• Detail: spiegazione estesa e human-readable dell’errore
• Status: il codice HTTP dello stato originario dell’errore
• Instance: un URI che identifica questa specifica istanza di errore. Questo può fungere da ID per
questa occorrenza dell'errore e / o un collegamento a maggiori dettagli sull'errore specifico

{
"type": "https://example.com/probs/out-of-credit",
"title": "You do not have enough credit.",
"detail": "Your current balance is 30, but that costs 50.",
“status”:400
"instance": "/account/12345/transactions/abc"
} <?xml version="1.0" encoding="UTF-8"?>
<problem xmlns="urn:ietf:rfc:7807">
<type>https://example.com/probs/out-of-credit</type>
<title>You do not have enough credit.</title>
<detail>Your current balance is 30, but that costs
50.</detail>
<status>400</status>
<instance>/account/12345/transactions/abc</instance>
</problem>

HTTP Support :Gestione dei Warning
La gestione degli errori non può coprire le situazioni dove un’esecuzione positiva della API implica
comunque delle conseguenze negative o di cui il Client deve essere avvisato
La specifica è al link: [ https://datatracker.ietf.org/doc/draft-cedik-http-warning/ ]
La specifica fornisce un pattern per rappresentare il concetto di warning nelle HTTP API
La specifica offre la possibilità di un formato unico in cui è racchiuso il warning grazie ad una
rappresentazione JSON
La specifica prevede uno specifico Header (Content-Warning) per indicare la presenza di un
warning nel contesto della data risposta, offrendo in questo un'unica modalità espressa dal valore
standard: embedded-warning

HTTP Support :Gestione dei Warning
POST /example HTTP/1.1
Host: example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
Content-Warning: "embedded-warning"; 1590190500
{ ...
"warnings": [
{ "detail": "Street name was too long. It has been shortened ...",
"instance": "https://example.com/shipments/3a186c51/msgs/c94d",
"status": "200",
"title": "Street name too long. It has been shortened.",
"type": "https://example.com/errors/shortened_entry" }, ... ],
"id": "3a186c51d4281acb",
"carrier_tracking_no": "84168117830018",
"price": 3.4, ... }

HTTP Support: Versioning
L’adozione di una politica di versionamento delle API può sembrare un argomento banale ma in
realtà nasconde differenti difficoltà dato che differenti sono le conseguenze rispetto alla strategia
scelta.
Quando affrontato nei termini stessi della definizione delle API, sono utilizzabili tre differenti
approcci:
 URI Versioning Es. http://host/v1/users
 Query String Versioning Es. http://host/users?api-version=1
 Header/Media Versioning Es. Accept: application/vnd.myname.v1+json
Avere un indicatore di versione diventa necessario specie in ambienti basati su container ma non
necessariamente sono da definirsi nelle API dato che è possibile affidarsi ad API Registry e alle
versioni, generalmente derivanti dal Semantic Versioning, relativo a sorgenti o specifiche
sottese alle API.

HTTP Support: Versioning
Viene considerato a volte molto più pragmatico evitare il versionamento e differenti
aziende hanno sperimentato soluzioni alternative:
Continuous Versioning:
Badoo -
https://www.slideshare.net/BadooDev/versioning-strategy-for-a-complex-internal-api
API Versioning for Zero Downtime
ING - https://www.youtube.com/watch?v=RvcDs_JLc0Y

Versioning? Io uso GraphQL... E se invece...

HTTP Support: Rate Limiting
E’ una buona pratica considerare delle limitazioni (quota) di
servizio per le differenti API e nel rispetto delle
classificazioni delle differenti tipologie di possibili
consumatori. Questo tipo di strategie vengono comunque
richieste in presenza di prodotti dedicati alla gestione delle
API
E’ possibile notificare il Client dello stato dei limiti di servizio
di una data API tramite apposito Header HTTP
[ https://tools.ietf.org/id/draft-polli-ratelimit-headers-02.html ]
In passato un meccanismo analogo era svolto con un altro
identificativo per lo Header che prevede un prefisso “X-”.
Questa prassi che interessa anche altri Header è stata
deprecata anche se I vecchi Header devono essere
supportati.
HTTP/1.1 200 Ok
RateLimit-Limit: 100
RateLimit-Remaining: 20
HTTP/1.1 429 Too Many Requests
Date: Mon, 05 Aug 2019 09:27:00 GMT
Retry-After: Mon, 05 Aug 2019 09:27:05
GMT
RateLimit-Reset: 5
RateLimit-Limit: 100
Ratelimit-Remaining: 0

REST API : Books

https://www.amazon.it/REST-Design-Rulebook-Mark-Masse/dp/1449310508/

https://www.manning.com/books/the-design-of-web-apis

https://www.amazon.it/Hands-RESTful-Design-Patterns-Practices/dp/1788992660

Open Source Licensing
Sono emersi nuovi tipi di licenza in risposta a Cloud Provider come Amazon che
attuano packaging, rebranding e profitti da progetti open source distribuiti sulla
loro piattaforma cloud.
Esempi popolari includono la Redis’Source Available License (RSAL), la
Server Side Public License (SSPL) di MongoDB, la Cockroach Community
License (CCL) o le licenze a cui è stata aggiunta la clausola Commons.

O.S. Licensing: Amazon Problem?
<< ...In practice, Amazon isn’t going to share source
code for AWS, or even its AWS-ified version of
Elasticsearch. They’re a closed platform people use
to run a lot of open software, not an open source
platform. So the license in effect said “hands off” to
AWS, not by saying they couldn’t use the code, but
by saying that if they did, they’d have to share alike.
Which they won’t. Why? Because releasing that code
ain’t in Amazon’s business model... >>
https://writing.kemitchell.com/2021/01/20/Righteous-
Expedient-Wrong.html

API & Licensing
Comparing Open-Source Software Licenses
https://www.youtube.com/watch?v=DDx6gjwU0K8

API & Licensing ( Risorse )
https://www.apilicens.se/en/
https://opendefinition.org/licenses/api/
https://wiki.p2pfoundation.net/Open_A
PI_License
https://matija.suklje.name/popular-lice
nses-in-openapi
Legal Challenges: https://nordicapis.com/challenges-the-api-industry-faces-
in-2021/

Non solo Microservizi: API, Prodotti e Piattaforme

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie Non solo Microservizi: API, Prodotti e Piattaforme

Ähnlich wie Non solo Microservizi: API, Prodotti e Piattaforme (20)

Mehr von Stefano Fago

Mehr von Stefano Fago (13)

Non solo Microservizi: API, Prodotti e Piattaforme