L'interfaccia impiegherà diversi protocolli standard per la comunicazione, in particolare:
ogni comunicazione di produzione avverrà attraverso canale confidenziale e autenticato tipo https o http2 (h2)
i messaggi saranno codificati in JSON (RFC8259, JSON)
l'autenticazione sarà gestita tramite OAUTH 2.0 (RFC6749, The OAuth 2.0 Authorization Framework) rispettivamente:
per le UI tramite grant Authorization Code con PKCE (RFC7636, PKCE for OAuth Public Clients)
per gli altri attori tramite grant Client Credentials
per entrambi: tramite grant Refresh Token per il rinnovo
nelle prossime revisioni della presente questi grant potranno essere sostituiti da altri grant relativi al protocollo stesso, sulla base delle features che si andranno ad aggiungere all'architettura, tipo: Provider di autenticazione esterni, distribuzione di una catena di certificati
ogni microservizio potrà inoltre fornire altre api che consentano comunicazioni in protocolli differenti, o con differenti meccanismi di autenticazione, ma resteranno delle “specificità” (ad esempio: un sistema di upload di chunk di blob, obbligare il client a codificarli in json potrebbe impattare le performance)
dove non diversamente specificato ogni campo null (o undefined) potrà (e dovrebbe) non essere trasmesso
Di seguito si considererà:
ogni url, o header http come codificato in USASCII (RFC7230, HTTP Encoding)
ogni messaggio json come codificato in UTF-8 (ogni uso dell'utf-8 è considerato senza BOM) (UTF Draft)
ogni codice verrà considerato come mappatura in UTF-8 di un nome in latin1 (ISO 8859-1) preso dal seguente sottoinsieme: [abcdefghijklmnopqrstuvwxyz0123456789_] con, in aggiunta, le seguenti limitazioni:
non potrà iniziare con i caratteri [0123456789_]
non potrà essere equivalente a una parola riservata di quelle indicate in questo documento
non potrà superare i 50 caratteri