{"id":34354,"date":"2019-10-31T21:57:51","date_gmt":"2019-10-31T18:57:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/pisali-api-porvali-xml-dva\/"},"modified":"2019-10-31T21:57:51","modified_gmt":"2019-10-31T18:57:51","slug":"pisali-api-porvali-xml-dva","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/pisali-api-porvali-xml-dva","title":{"rendered":"API scritti \u2014 XML strappato (due)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Il primo API di Mo\u0451goSklada \u00e8 apparso 10 anni fa. Da allora lavoriamo sulle versioni esistenti dell'API e sviluppiamo nuove versioni. E alcune versioni dell'API sono gi\u00e0 state obsolete. <\/p>\n

In questo articolo troverai molte informazioni: come \u00e8 stato creato l'API, a cosa serve per i servizi cloud, cosa offre agli utenti, quali ostacoli abbiamo incontrato e cosa vogliamo fare in futuro.
\n<\/a><\/noindex>
\nMi chiamo Oleg Alekseev oalexeev<\/a><\/noindex>, sono il direttore tecnico e cofondatore di Mo\u0451goSklada. <\/p>\n

Perch\u00e9 fare un'API per il servizio<\/h2>\n

\nI nostri clienti, che sono decine di migliaia di imprenditori, utilizzano attivamente soluzioni cloud: banche online, negozi internet, gestione delle merci, CRM. Una volta collegati a uno, \u00e8 difficile fermarsi. E ora il quinto, l'ottavo, il decimo servizio rende il lavoro degli imprenditori pi\u00f9 facile, ma i dati tra questi servizi cloud devono essere trasferiti manualmente dagli utenti. Il lavoro si trasforma in un incubo.<\/p>\n

Una soluzione ovvia \u00e8 quella di consentire agli utenti di trasferire dati tra servizi cloud. Ad esempio, importare ed esportare dati come file che possono poi essere caricati nel servizio desiderato. I file di solito vengono modificati nel formato richiesto da ciascun servizio. Questo \u00e8 un lavoro manuale pi\u00f9 o meno semplice, ma con l'aumento di questi servizi, diventa sempre pi\u00f9 difficile da gestire.<\/p>\n

Pertanto, il passo successivo \u00e8 l'API. Con essa, il servizio cloud beneficia del collegamento di pi\u00f9 servizi in un unico punto. La creazione di un ecosistema del genere attira nuovi clienti grazie alle opportunit\u00e0 aggiuntive. Un prodotto con nuove funzionalit\u00e0 diventa pi\u00f9 vantaggioso e utile.<\/p>\n

Se si creano interfacce di programmazione proprie, si attirano venditori esterni sotto forma di programmatori che conoscono il proprio prodotto grazie all'API. Iniziano a sviluppare soluzioni basate sull'API proposta e guadagnano denaro automatizzando i compiti dei loro clienti.<\/p>\n

Il sistema di contabilit\u00e0 di MoegoSklanda si basa su processi semplici. L'obiettivo principale \u00e8 lavorare con documenti primari, consentire la ricezione e la spedizione di merci e fornire report aziendali basati sui documenti primari. \u00c8 anche possibile trasferire dati, ad esempio verso software di contabilit\u00e0 cloud, e riceverli da sistemi bancari o punti vendita. Inoltre, collaboriamo con negozi online: otteniamo informazioni sui prodotti e inviamo dati sulle giacenze.<\/p>\n

\"API
\n<\/p>\n

Il primo API di MoegoSklanda<\/h2>\n

\nNegli ultimi 10 anni di attivit\u00e0 di MoegoSklanda con API, abbiamo accumulato una variet\u00e0 di integrazioni che consentono lo scambio di dati, l'interazione con le banche, l'effettuazione di pagamenti e l'uso di telefonia esterna.<\/p>\n

Nel primo anno abbiamo creato la possibilit\u00e0 di esportare qualsiasi dato in formato XML. All'epoca, per gli utenti era molto pi\u00f9 chiaro e consueto mantenere i dati offline piuttosto che in qualche cloud, e abbiamo fornito loro questa opzione. L'esportazione veniva avviata tramite un'esportazione manuale dall'interfaccia. Quindi non si poteva nemmeno parlare di API. <\/p>\n

Allora abbiamo iniziato a collaborare con l'azienda Rusagro: avevano gi\u00e0 utilizzato un ERP 'mature' per la pianificazione della produzione e delle vendite, mentre il caricamento dei vagoni negli stabilimenti \u00e8 stato automatizzato in \u041c\u043e\u0435\u043c\u0421\u043a\u043b\u0430\u0434\u0435. Cos\u00ec sono emerse le prime basi di una vera API: lo scambio tra il nostro servizio e l'ERP avveniva tramite l'invio di un grande file con i dati su tutti i tipi di documenti. <\/p>\n

Questa \u00e8 una buona opzione per lo scambio di dati in batch, ma insieme ai documenti era necessario trasmettere anche le loro dipendenze: informazioni sui prodotti, sui partner commerciali e sui magazzini. Generare un simile ammasso durante l'esportazione non \u00e8 cos\u00ec difficile, ma \u00e8 piuttosto complicato da analizzare durante l'importazione, poich\u00e9 in un unico pacchetto arrivano tutte le informazioni: sia sui nuovi documenti che su quelli gi\u00e0 esistenti.<\/p>\n

Il primo XML API non \u00e8 durato a lungo: dopo due anni abbiamo iniziato la sua ristrutturazione. Anche all'inizio del suo funzionamento abbiamo commesso alcuni errori nella costruzione dell'interfaccia programmativa.<\/p>\n

\"API
\nCome \u00e8 stato realizzato l'XML API: un'illustrazione di uno dei nostri architetti. A proposito, aspettatevi i suoi articoli.<\/i><\/p>\n

Ecco i nostri principali errori:<\/p>\n

    \n
  1. La serializzazione JAXB \u00e8 stata eseguita direttamente sui bean delle entit\u00e0. Per comunicare con il database utilizziamo Hibernate, e la stessa serializzazione JAXB \u00e8 stata applicata a questi bean. Questo errore \u00e8 emerso quasi immediatamente: qualsiasi aggiornamento della struttura dei dati richiedeva di avvisare urgentemente tutti coloro che utilizzavano l'API, oppure di costruire delle soluzioni temporanee che garantissero la compatibilit\u00e0 con la precedente struttura dei dati.<\/li>\n
  2. L'API \u00e8 cresciuto come un'aggiunta, e inizialmente non abbiamo definito quale parte del prodotto costituisse. Non ci siamo chiesti se l'API fosse qualcosa di importante, se fosse necessario mantenere la retrocompatibilit\u00e0 per i suoi primi clienti. A un certo punto, il numero degli utenti dell'API rappresentava circa il 5% del totale, e non si prestava loro attenzione. La filtrazione universale realizzata all'epoca ha portato a usarci come backend. Questa filtrazione non era del tutto GraphQL, ma qualcosa di simile \u2014 funzionava tramite un mucchio di parametri nella stringa della query. Con uno strumento cos\u00ec potente, gli utenti hanno trovato difficile resistere, e le richieste sono state indirizzate a noi in modo che fossero inviate direttamente dall'interfaccia utente dei loro negozi online. La situazione si \u00e8 rivelata una spiacevole sorpresa, poich\u00e9 fornire tale servizio richiederebbe una diversa tariffazione e, in generale, una diversa comprensione dell'API come prodotto.<\/li>\n
  3. Poich\u00e9 l'API \u00e8 stato sviluppato come un prodotto secondario, la documentazione dell'API \u00e8 stata realizzata e pubblicata come un ripiego \u2014 attraverso il reverse engineering. Questo approccio pu\u00f2 sembrare semplice e comodo, ma contraddice le normative contrattuali. Si tratta di avere un componente con uno schema di lavoro predeterminato. Lo sviluppatore lo implementa secondo questo schema e l'obiettivo, il componente viene testato, e il cliente riceve un prodotto conforme alle intenzioni dell'analista. Il reverse engineering, invece, immette sul mercato un prodotto che esiste semplicemente: con soluzione temporanee, approcci bizzarri e un'invenzione di ruote al posto della funzionalit\u00e0 necessaria. <\/li>\n
  4. L'intero flusso di richieste che arrivava tramite API poteva essere analizzato al massimo come un log di Nginx o di un server applicativo. Questo non permetteva di identificare le aree tematiche, a meno di suddividerle per utenti e abbonati. Senza la possibilit\u00e0 di regolare la registrazione delle applicazioni o dei clienti, diventa impossibile analizzare la situazione. Questo problema ha avuto un impatto minimo sullo sviluppo dell'API, si tratta pi\u00f9 di comprendere la sua domanda e la completezza delle funzionalit\u00e0.<\/li>\n<\/ol>\n

    <\/p>\n

    Tentativo numero due: REST API<\/h2>\n

    \nNel 2010 abbiamo cercato di costruire un sistema di integrazione con un software di contabilit\u00e0 online \u2014 BuchSoft. Non ha avuto successo. Tuttavia, durante il processo di integrazione \u00e8 emerso un API completo: un servizio REST di scambio, dove non c'erano libert\u00e0 come le chiamate RPC per le operazioni. Tutta la comunicazione con l'API \u00e8 stata standardizzata secondo il formato REST: nella stringa di richiesta \u00e8 contenuto il nome dell'entit\u00e0, e l'operazione da eseguire \u00e8 specificata tramite il metodo HTTP. Abbiamo aggiunto la possibilit\u00e0 di filtrare in base al momento di aggiornamento delle entit\u00e0, dando agli utenti la possibilit\u00e0 di costruire la replicazione con i propri sistemi.<\/p>\n

    Nello stesso anno \u00e8 stato introdotto l'API per l'esportazione delle giacenze e dei prodotti. Attraverso l'API sono diventate disponibili per gli utenti le parti pi\u00f9 preziose del sistema: lo scambio di documenti primari e i dati di calcolo sulle giacenze e sui costi dei prodotti.<\/p>\n

    Nel dicembre 2015, RetailCRM ha pubblicato la prima libreria di terze parti per accedere al nostro API. \u00c8 stata utilizzata piuttosto attivamente, mentre la popolarit\u00e0 del servizio in generale cresceva, e il carico sull'API aumentava pi\u00f9 rapidamente di quello sull'interfaccia web. Un giorno, la crescita si \u00e8 trasformata in un'impennata del carico. <\/p>\n

    \"API
    \n
    \n\"API
    \n
    \nE questa impennata, indicata dalla freccia a sinistra, ha lasciato completamente sbalordito il server che gestisce il nostro API. Abbiamo trascorso una settimana a capire cosa stava generando quel carico. Si \u00e8 scoperto che erano proprio quelle richieste trasmesse al nostro API dai fronti dei clienti. Circa 50 clienti hanno assorbito tutto. In quel momento abbiamo capito uno dei nostri errori: la totale assenza di limiti. <\/p>\n

    Alla fine abbiamo introdotto un limite al numero di richieste simultanee. Da un singolo account ora \u00e8 possibile aprire al massimo due richieste contemporaneamente. Questo \u00e8 sufficiente per lavorare in modalit\u00e0 replica per lo scambio di dati in modalit\u00e0 batch. Coloro che desideravano utilizzare i nostri servizi come backend erano costretti a seguire maggiormente le tariffe, poich\u00e9 hanno dovuto implementare nel proprio software la gestione di pi\u00f9 account.<\/p>\n

    Mettiamo in ordine<\/h2>\n

    \nGi\u00e0 dal 2014, la domanda per l'API esistente \u00e8 diventata una parte importante del business, e l'API stessa generava il pi\u00f9 grande volume di dati nello scambio informatico con i clienti. Nel 2015 abbiamo avviato un progetto per mettere a posto l'API. Abbiamo scelto il formato JSON invece di XML e abbiamo iniziato a costruirlo sulla base delle caratteristiche emerse dalla realizzazione della versione precedente:<\/p>\n

      \n
    1. Possibilit\u00e0 di gestire le versioni. La gestione delle versioni consente di sviluppare una nuova versione senza influenzare l'applicazione esistente e senza interrompere il lavoro degli utenti. <\/li>\n
    2. Possibilit\u00e0 per l'utente di vedere i metadati nella risposta che riceve.<\/li>\n
    3. La possibilit\u00e0 di scambiare grandi documenti. Quando elaboriamo un documento con pi\u00f9 di 4-5 mila voci, questo diventa un problema per il server: transazione lunga, richiesta HTTP lunga. Abbiamo costruito un meccanismo speciale che consente di aggiornare il documento in parti e gestire singole voci di quel documento, inviandole al server.<\/li>\n
    4. Strumenti per la replicazione - presenti anche nella versione precedente.<\/li>\n
    5. Limiti di carico - come un'eredit\u00e0 degli errori commessi nella versione precedente. Abbiamo introdotto limiti sul numero di richieste in un dato intervallo di tempo, sul numero di richieste parallele e sulle richieste da un singolo indirizzo IP.<\/li>\n<\/ol>\n

      \nDa quel momento abbiamo rilasciato due versioni minori dell'API e lanciato diverse API specializzate, ma in generale l'approccio \u00e8 rimasto invariato. Il nuovo formato di scambio e la nuova architettura hanno permesso di risolvere i difetti nell'API molto pi\u00f9 rapidamente.<\/p>\n

      API di MoioScald oggi<\/h2>\n

      \nOggi API di MoioScald risolve molte attivit\u00e0:<\/p>\n