{"id":6151,"date":"2019-07-03T17:09:14","date_gmt":"2019-07-03T15:09:14","guid":{"rendered":"https:\/\/www.intesys.it\/journal\/?p=6151"},"modified":"2022-06-07T11:47:16","modified_gmt":"2022-06-07T09:47:16","slug":"api-design-progettare-con-un-approccio-outside-in","status":"publish","type":"post","link":"https:\/\/www.intesys.it\/journal\/digital-transformation\/api-design-progettare-con-un-approccio-outside-in\/","title":{"rendered":"API Design: progettare con un approccio outside-in"},"content":{"rendered":"

Indice dei contenuti<\/span>
  1. Le due prospettive dell\u2019API Design: inside-out e outside-in<\/a><\/li>
  2. API Design: i vantaggi di un approccio outside-in<\/a><\/li><\/ol><\/div><\/div><\/p>[vc_row type=”in_container” full_screen_row_position=”middle” column_margin=”default” column_direction=”default” column_direction_tablet=”default” column_direction_phone=”default” scene_position=”center” text_color=”dark” text_align=”left” row_border_radius=”none” row_border_radius_applies=”bg” overflow=”visible” overlay_strength=”0.3″ gradient_direction=”left_to_right” shape_divider_position=”bottom” bg_image_animation=”none”][vc_column column_padding=”no-extra-padding” column_padding_tablet=”inherit” column_padding_phone=”inherit” column_padding_position=”all” column_element_spacing=”default” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” column_border_radius=”none” column_link_target=”_self” column_position=”default” gradient_direction=”left_to_right” overlay_strength=”0.3″ width=”1\/1″ tablet_width_inherit=”default” tablet_text_alignment=”default” phone_text_alignment=”default” animation_type=”default” bg_image_animation=”none” border_type=”simple” column_border_width=”none” column_border_style=”solid”][vc_column_text]In un mercato sempre pi\u00f9 dinamico e competitivo, le API sono un asset importante per creare valore per il business<\/strong>, favorendo la capacit\u00e0 di un\u2019azienda di accelerare e governare l\u2019innovazione<\/a>.<\/p>\n

    Abilitare la propria Architettura IT a rispondere alle richieste del mercato \u00e8 il risultato di un percorso strategico in cui le API svolgono la funzione di integrare dati e applicativi<\/strong> per connettere non solo le risorse interne all\u2019organizzazione, ma anche quelle esterne (clienti, partner e fornitori).<\/p>\n

    Maggiore \u00e8 la capacit\u00e0 di un\u2019azienda di adattarsi al mercato in modo agile, scalabile e veloce<\/strong>, migliore sar\u00e0 il valore offerto agli utenti e la capacit\u00e0 competitiva futura.
    \nPer questo le risorse tecnologiche devono essere costruite per essere riutilizzabili e in grado di creare agilmente nuovi servizi. Come?     Progettando il Design delle API con un approccio user-centered<\/a>, che esplora i bisogni, i desideri e le esigenze degli\u00a0utilizzatori per creare delle soluzioni che li soddisfino nel tempo.<\/p>\n

    Le due prospettive dell\u2019API Design: inside-out e outside-in<\/h2>\n

    Una API pu\u00f2 essere disegnata attraverso due approcci: inside-out e outside-in.<\/p>\n

    Nel primo caso, l\u2019approccio inside-out<\/strong> fa leva sulle strutture presenti, assemblando i servizi gi\u00e0 esistenti. Anche se pu\u00f2 sembrare la scelta pi\u00f9 naturale, le API risultanti sono molto complicate da utilizzare perch\u00e9 viene esposta la complessit\u00e0 insita dei sistemi backend.
    \nI sistemi sottostanti vengono mappati dai\u00a0livelli superiori, senza per\u00f2 focalizzare l\u2019attenzione su ci\u00f2 che serve ai consumatori finali.<\/p>\n

    Riferendosi ad un esempio nel mondo finance, si pensi ad un\u2019architettura informatica che deve integrare\u00a0applicativi gestionali come il sistema SAP o\u00a0AS\/400<\/strong>: replicare nei livelli superiori\u00a0i servizi di questi sistemi significa portarsi dietro\u00a0un bagaglio di complessit\u00e0 come parametri e linguaggi specifici di dominio.<\/p>\n

    Seguendo questo approccio, non si riesce ad ottenere il massimo vantaggio di una API oriented Architecture<\/a> multistrato a 3 livelli, dove ogni strato \u00e8 ben definito e ha una sua responsabilit\u00e0 precisa. Ci\u00f2 significa che lo strato di Process API<\/strong> \u00e8 assente o non ottimizzato e non sar\u00e0 molto efficace il livello di Experience API<\/strong> (per massimizzare le performance del front-end) perch\u00e9 in questo caso esporr\u00e0 direttamente le logiche dei sistemi di back-end.<\/p>\n

    \"\"<\/p>\n

    Nel caso invece dell\u2019approccio outside-in<\/strong>, la progettazione di una API parte dai bisogni dell\u2019utilizzatore<\/a>, indipendente dai sistemi sottostanti. In un secondo momento, si fanno poi considerazioni sui sistemi presenti quali formati, connessioni e sistemi di back-end.
    \nIl focus di questo approccio \u00e8 studiare il Design delle API<\/strong> per renderle il pi\u00f9 semplici possibili per chi deve consumarle, ossia intuitive, ben documentate, riutilizzabili e compatibili.<\/p>\n

    Il risultato sono API che offrono funzionalit\u00e0 in modo generico, adattandosi ad un\u2019ampia gamma di utilizzatori.
    \nLe API pubbliche, per esempio, dovrebbero sempre seguire questo approccio. Si pensi all\u2019applicativo per i pagamenti via intranet \u201c    Stripe<\/a>\u201d, che fornisce API per integrare i sistemi di pagamento favorendo i loro utilizzatori con un design centrato sulle funzionalit\u00e0 desiderate.<\/strong><\/p>\n

    API Design: i vantaggi di un approccio outside-in<\/h2>\n

    Mentre l\u2019approccio inside-out \u00e8 naturalmente pi\u00f9 facile e immediato, l\u2019approccio outside-in prevede uno sforzo maggiore nel progettare e implementare le API perch\u00e9 andranno integrate con pi\u00f9 sistemi del backend. La criticit\u00e0 sta proprio nell\u2019integrare le API<\/strong> con sistemi che hanno logiche diverse, una terminologia disomogenea, parametri da tradurre e informazioni da mappare.<\/p>\n

    Per farlo \u00e8 necessario studiare la progettazione delle API attraverso una fase di Design<\/strong> in cui l\u2019obiettivo \u00e8 comprendere come, quante e quali API progettare per interrogare i sistemi sottostanti in modo efficiente ed efficace. In questa fase \u00e8 fondamentale costruire un glossario di termini<\/strong> per definire un linguaggio univoco a tutte le API, definire le relazioni tra le entit\u00e0, mappare e documentare il tutto per dare omogeneit\u00e0.<\/p>\n

    A tale scopo, il paradigma API first<\/strong> prevede l\u2019utilizzo di un linguaggio di definizione standard delle API (come ad esempio Swagger\/OpenAPI<\/a>), che consente di strutturarle, definirle e descriverle per consentire la chiamata di terzi nel momento in cui vengono pubblicate.<\/p>\n

    Se con l’approccio outside-in l\u2019investimento e lo sforzo iniziale \u00e8 maggiore, i vantaggi saranno poi nel lungo termine, quali:<\/p>\n