Menu

Contattaci
Logo
Stampa

Gestione delle API

Interfacce aperte. Confini chiari.

Partner e applicazioni hanno bisogno di interfacce sul cui comportamento possano fare affidamento. Progettiamo i contratti API, configuriamo accesso e protezione a livello di gateway e organizziamo versioni, documentazione e rilasci lungo l'intero ciclo di vita.

Codice sorgente JavaScript su un monitor, immagine simbolica
Linee guida API e catalogo delle interfacce · Pianificazione e realizzazione a cura di OTOKO®

Cosa affidate a OTOKO®

Di cosa ci occupiamo per voi.

Iniziamo dalle operazioni dei sistemi collegati: quali dati richiedono, quali stati possono modificare e come riconoscono gli errori? REST, GraphQL o gRPC vengono scelti in base al caso d'uso. La descrizione impiega il formato adatto al protocollo, ad esempio OpenAPI per le API HTTP corrispondenti. Oltre al payload vengono definiti paginazione, timeout, risposte di errore e comportamento in caso di nuovi tentativi. Esempi e casi di test aiutano i team che utilizzano l'interfaccia a integrarla prima del rilascio in produzione.

Il possibile ambito del servizio

  • Linee guida API con convenzioni di denominazione, formati degli errori, versionamento e requisiti di sicurezza
  • Catalogo delle interfacce con specifica OpenAPI e un responsabile per ogni API
  • Realizzazione del gateway con Kong, Apigee o Azure API Management, collegamento alla vostra gestione delle identità tramite OAuth 2.0 e OpenID Connect
  • Portale per partner e sviluppatori con gestione degli accessi, chiavi e report di utilizzo
  • Ciclo di vita con processo di approvazione, deprecazione delle vecchie versioni e notifiche delle modifiche

Definiamo l'ambito concreto, il vostro contributo e i criteri di collaudo prima dell'inizio.

Gli aspetti tecnici, spiegati con chiarezza

Ecco come svolgiamo il lavoro.

01

Gateway e applicazione svolgono controlli diversi

Un gateway può gestire gli accessi, limitare le richieste e applicare regole tecniche. Se un determinato utente possa leggere un ordine specifico deve deciderlo, in aggiunta, il servizio competente. Pianifichiamo la verifica dei token, le identità di servizio, l'assegnazione ai tenant e il logging lungo questo confine. Per le chiamate in scrittura si chiarisce come vengono gestite le richieste ripetute. Per le versioni precedenti è previsto un processo di deprecazione tracciabile, in modo che le modifiche non interrompano inaspettatamente i collegamenti con i partner.

02

Collaudare insieme ai consumer

I test di contratto verificano la struttura concordata; i test di integrazione e di carico ne verificano anche il comportamento. Testiamo accessi respinti, input non validi e timeout, così come le chiamate riuscite. Il passaggio di consegne comprende la specifica, la configurazione del gateway e le responsabilità. Per iniziare abbiamo bisogno dei consumer tipici, delle ipotesi di carico e delle operazioni di business che l'API deve rendere possibili.

Sala riunioni nell'ufficio OTOKO® di Colonia

Un risultato verificabile

La base per proseguire il vostro lavoro.

  1. Linee guida API e catalogo delle interfacce
  2. API gateway operativo con integrazione delle identità
  3. Portale per sviluppatori con documentazione per ogni API

Il passaggio di consegne unisce realizzazione e documentazione. Verifichiamo insieme i casi concordati e annotiamo le attività ancora aperte.

Il vostro progetto nel dettaglio

Gestire le interfacce come accesso controllato ai vostri sistemi.

Progettiamo le API in modo che team interni e partner esterni possano utilizzarle in modo affidabile. Ne fanno parte un contratto comprensibile, diritti di accesso chiari e una gestione operativa che affronta errori e sovraccarichi in modo trasparente.

Dalla funzione di business a un contratto API stabile

Un'API dovrebbe offrire una funzione di business comprensibile e non esporre all'esterno, senza filtri, le tabelle di un sistema interno. Definiamo risorse, azioni, campi obbligatori e risposte di errore insieme ai team che la utilizzano. Dati di esempio e una descrizione leggibile da macchina facilitano l'integrazione; le regole di business restano documentate in modo esplicito.

Le modifiche vengono valutate in base al loro impatto. Un campo opzionale aggiuntivo va trattato diversamente da un nuovo valore obbligatorio o da un significato modificato. Pianifichiamo il versionamento, i periodi di transizione e la comunicazione agli utenti noti. Così un aggiornamento interno del database non deve per forza compromettere tutte le applicazioni collegate nello stesso momento.

Proteggere insieme gateway, identità e backend

Sul gateway possono essere applicate regole centralizzate per autenticazione, limitazione delle richieste e routing. L'autorizzazione di business deve comunque essere verificata nel servizio competente: un cliente autenticato correttamente non deve poter leggere automaticamente i dati di un altro cliente. Consideriamo quindi l'intera catena della richiesta.

Per la gestione operativa concordiamo i budget di tempo di risposta, i timeout e la gestione dei nuovi tentativi. Gli identificativi di correlazione collegano i log tra più sistemi, senza registrare in modo indiscriminato contenuti sensibili delle richieste. Un accesso per sviluppatori con esempi e un ambiente di test adeguato aiuta i partner a individuare errori prima del collegamento in produzione.

Scenario di progetto illustrativo

In che modo il servizio aiuta nella pratica quotidiana.

Esempio: i partner commerciali devono poter consultare lo stato dei propri ordini. Mettiamo a disposizione un'API circoscritta, associamo gli accessi alla rispettiva organizzazione e proteggiamo l'ERP da un carico incontrollato. Le modifiche di stato interne vengono tradotte in risposte esterne stabili.

Questo esempio illustra un possibile svolgimento e non costituisce una referenza cliente.

Prima del primo passo

Le vostre domande su Gestione delle API.

Un API gateway è sufficiente per la sicurezza?

No. Integra i controlli di sicurezza dell'applicazione. Le autorizzazioni applicative e l'elaborazione sicura dei dati devono essere implementate nei servizi responsabili.

I partner esterni possono ricevere un ambiente di test?

Sì, se ambito e accesso ai dati sono concordati. Pianifichiamo credenziali di accesso separate, dati di test adeguati e un percorso verso il rilascio in produzione.

Il vostro progetto

Quale compito volete affrontare?

Descrivete la vostra situazione di partenza e il risultato desiderato. Il servizio selezionato viene riportato nella richiesta di contatto.

Richiedete questo servizio

I nostri partner

  • Microsoft
  • Microsoft Azure
  • Amazon AWS
  • Google Cloud
  • Thales Group
  • Arrow ECS
  • Vodafone
  • IBM
  • Veeam
  • Atlassian
  • JetBrains
  • NinjaOne
  • OPSWAT
  • Utimaco
  • Eviden

Accessibilità

Adatta la visualizzazione alle tue esigenze.

Per questa pagina non è ancora disponibile una versione in linguaggio semplice.

Le impostazioni valgono attualmente per questa visita. Puoi consentirne il salvataggio permanente nelle impostazioni cookie.