{"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\/fr\/blog\/administrirovanie\/pisali-api-porvali-xml-dva","title":{"rendered":"APIs \u00e9crits \u2014 XML d\u00e9chir\u00e9 (deux)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La premi\u00e8re API de MoegoSklada est apparue il y a 10 ans. Depuis tout ce temps, nous travaillons sur les versions existantes de l'API et en d\u00e9veloppons de nouvelles. D\u00e9j\u00e0 plusieurs versions de l'API ont \u00e9t\u00e9 mises au rebut. <\/p>\n

Cet article contiendra beaucoup de choses : comment l'API a \u00e9t\u00e9 cr\u00e9\u00e9e, pourquoi elle est n\u00e9cessaire pour un service cloud, ce qu'elle apporte aux utilisateurs, sur quelles emb\u00fbches nous avons tr\u00e9buch\u00e9 et ce que nous voulons faire ensuite.
\n<\/a><\/noindex>
\nJe m'appelle Oleg Alexeev oalexeev<\/a><\/noindex>, je suis directeur technique et cofondateur de MoegoSklada. <\/p>\n

Pourquoi cr\u00e9er une API pour le service<\/h2>\n

\nNos clients, qui comptent des dizaines de milliers d'entrepreneurs, utilisent activement des solutions cloud : services bancaires, boutiques en ligne, gestion des stocks, CRM. Une fois connect\u00e9 \u00e0 l'un, il devient difficile de s'arr\u00eater. Et voil\u00e0 d\u00e9j\u00e0 le cinqui\u00e8me, le huiti\u00e8me, le dixi\u00e8me service qui facilite le travail des entrepreneurs, mais les utilisateurs doivent transf\u00e9rer manuellement les donn\u00e9es entre ces services cloud. Le travail se transforme en cauchemar.<\/p>\n

La solution \u00e9vidente est de permettre aux utilisateurs de transf\u00e9rer des donn\u00e9es entre les services cloud. Par exemple, importer et exporter des donn\u00e9es sous forme de fichiers, qui peuvent ensuite \u00eatre t\u00e9l\u00e9charg\u00e9s dans le service appropri\u00e9. Les fichiers sont g\u00e9n\u00e9ralement adapt\u00e9s au format de chaque service. C'est un travail manuel plus ou moins simple, mais avec l'augmentation du nombre de ces services, il devient de plus en plus difficile de le r\u00e9aliser.<\/p>\n

Ainsi, la prochaine \u00e9tape est l'API. Avec cela, le service cloud b\u00e9n\u00e9ficie de la connexion de plusieurs services en un seul point. L'apparition d'un tel \u00e9cosyst\u00e8me attire de nouveaux clients gr\u00e2ce \u00e0 des fonctionnalit\u00e9s suppl\u00e9mentaires. Un produit avec une nouvelle fonctionnalit\u00e9 devient plus rentable et utile.<\/p>\n

En cr\u00e9ant des interfaces de programmation propres, cela attire des vendeurs tierce partie sous la forme de programmeurs qui connaissent votre produit gr\u00e2ce \u00e0 l'API. Ils commencent \u00e0 construire des solutions bas\u00e9es sur l'API propos\u00e9e et gagnent de l'argent en automatisant les t\u00e2ches pour leurs clients.<\/p>\n

Le syst\u00e8me de comptabilit\u00e9 de MoegoSklada est construit sur des processus simples. L'essentiel est de travailler avec des documents de base, la possibilit\u00e9 de recevoir et d'exp\u00e9dier des marchandises, puis d'obtenir des rapports pour les entreprises bas\u00e9s sur ces documents. Il y a aussi le transfert de donn\u00e9es, par exemple vers une comptabilit\u00e9 cloud, et leur r\u00e9ception depuis des syst\u00e8mes bancaires ou des points de vente. De plus, nous travaillons avec des boutiques en ligne : nous obtenons des informations sur les produits et envoyons des donn\u00e9es sur les stocks.<\/p>\n

\"APIs
\n<\/p>\n

Premi\u00e8re API de MonInventaire<\/h2>\n

\nAu cours de ses 10 ann\u00e9es d'activit\u00e9 avec l'API, MonInventaire a d\u00e9velopp\u00e9 toutes sortes d'int\u00e9grations permettant d'\u00e9changer des donn\u00e9es, de travailler avec des banques, de traiter des paiements et d'utiliser la t\u00e9l\u00e9phonie externe.<\/p>\n

Dans la premi\u00e8re ann\u00e9e, nous avons rendu possible l'exportation de toutes les donn\u00e9es au format XML. \u00c0 l'\u00e9poque, il \u00e9tait bien plus compr\u00e9hensible et habituel pour les utilisateurs de conserver les donn\u00e9es hors ligne plut\u00f4t que dans un cloud, et nous leur avons donn\u00e9 cette opportunit\u00e9. L'exportation \u00e9tait lanc\u00e9e manuellement depuis l'interface. On ne pouvait donc pas encore parler d'une v\u00e9ritable API. <\/p>\n

\u00c0 cette \u00e9poque, nous avons commenc\u00e9 \u00e0 collaborer avec l'entreprise Rusagro \u2014 ils utilisaient d\u00e9j\u00e0 un ERP 'mature' pour la planification de la production et de la vente, tandis que nous avons automatis\u00e9 le chargement des wagons dans les usines avec MonInventaire. Ainsi, nous avons eu nos premiers balbutiements d'une v\u00e9ritable API : l'\u00e9change entre notre service et l'ERP se faisait par l'envoi d'un grand fichier contenant les donn\u00e9es sur tous les types de documents. <\/p>\n

C'est une option pas mal pour l'\u00e9change de donn\u00e9es en lot, mais avec les documents, il fallait \u00e9galement transmettre leurs d\u00e9pendances : des informations sur les produits, les partenaires et les entrep\u00f4ts. Ce genre de fouillis n'est pas si difficile \u00e0 g\u00e9n\u00e9rer lors de l'exportation, mais c'est plut\u00f4t compliqu\u00e9 \u00e0 d\u00e9chiffrer lors de l'importation, car dans un seul paquet se trouvent toutes les informations : \u00e0 la fois sur les nouveaux documents et sur ceux d\u00e9j\u00e0 existants.<\/p>\n

La premi\u00e8re API XML n'a pas dur\u00e9 longtemps \u2014 apr\u00e8s deux ans, nous avons commenc\u00e9 \u00e0 la reconstruire. D\u00e8s le d\u00e9marrage de son fonctionnement, nous avons fait plusieurs erreurs dans la conception de l'interface du programme.<\/p>\n

\"APIs
\nComment l'API XML a \u00e9t\u00e9 r\u00e9alis\u00e9e : illustration d'un de nos architectes. D'ailleurs, attendez-vous \u00e0 ses articles.<\/i><\/p>\n

Voici nos principales erreurs :<\/p>\n

    \n
  1. Le balisage JAXB a \u00e9t\u00e9 fait directement sur les entit\u00e9s beans. Pour communiquer avec la base de donn\u00e9es, nous utilisons Hibernate, et le balisage JAXB a \u00e9galement \u00e9t\u00e9 fait sur ces m\u00eames beans. Cette erreur a \u00e9merg\u00e9 presque imm\u00e9diatement : toute mise \u00e0 jour de la structure des donn\u00e9es n\u00e9cessitait d'informer d'urgence tous ceux qui utilisaient l'API, ou de construire des b\u00e9quilles pour assurer la compatibilit\u00e9 avec la structure de donn\u00e9es pr\u00e9c\u00e9dente.<\/li>\n
  2. L'API a \u00e9merg\u00e9 comme un compl\u00e9ment, et au d\u00e9part, nous n'avons pas d\u00e9fini quelle part du produit il repr\u00e9sentait. Nous n'avons pas non plus r\u00e9fl\u00e9chi \u00e0 savoir si l'API \u00e9tait quelque chose d'important, ni s'il \u00e9tait n\u00e9cessaire de maintenir la compatibilit\u00e9 avec les premi\u00e8res versions. Pendant un moment, le nombre d'utilisateurs de l'API repr\u00e9sentait environ 5 % d'un nombre total d\u00e9j\u00e0 faible, et ils n'ont pas attir\u00e9 notre attention. La filtration universelle mise en place \u00e0 l'\u00e9poque a conduit \u00e0 ce que nous soyons utilis\u00e9s comme backend. Cette filtration n'\u00e9tait pas v\u00e9ritablement GraphQL, mais quelque chose de similaire \u2014 elle fonctionnait \u00e0 travers une multitude de param\u00e8tres de la cha\u00eene de requ\u00eate. Avec un outil aussi puissant, il \u00e9tait difficile pour les utilisateurs de s'en passer, et nous avons commenc\u00e9 \u00e0 recevoir des requ\u00eates directement depuis l'interface utilisateur de leurs boutiques en ligne. La situation s'est r\u00e9v\u00e9l\u00e9e \u00eatre une mauvaise surprise, car la fourniture d'un tel service devrait n\u00e9cessiter une tarification diff\u00e9rente et une compr\u00e9hension totalement diff\u00e9rente de l'API en tant que produit.<\/li>\n
  3. \u00c9tant donn\u00e9 que l'API s'est d\u00e9velopp\u00e9e non pas comme un produit principal, la documentation de l'API a \u00e9t\u00e9 produite et publi\u00e9e de mani\u00e8re r\u00e9siduelle \u2014 par ing\u00e9nierie inverse. Ce chemin semble assez simple et pratique, mais est en contradiction avec le travail contractuel. C'est lorsqu'il y a un certain composant avec un sch\u00e9ma de travail pr\u00e9d\u00e9fini. Le d\u00e9veloppeur le met en \u0153uvre conform\u00e9ment \u00e0 ce sch\u00e9ma et \u00e0 cet objectif, le composant est test\u00e9, le client re\u00e7oit un produit conforme \u00e0 la vision de l'analyste. L'ing\u00e9nierie inverse, quant \u00e0 elle, met sur le march\u00e9 un produit qui existe simplement : avec des solutions de contournement, des d\u00e9cisions \u00e9tranges et des solutions improvis\u00e9es au lieu de la fonctionnalit\u00e9 requise. <\/li>\n
  4. Tout le flux de requ\u00eates re\u00e7ues via l'API ne pouvait \u00eatre analys\u00e9 que par les journaux de Nginx ou du serveur d'application. Cela ne permettait pas de distinguer les domaines d'application, sauf \u00e0 les classer par utilisateurs et abonn\u00e9s. En l'absence de possibilit\u00e9s pour r\u00e9guler l'enregistrement des applications ou des clients, il devient impossible d'analyser la situation. Ce probl\u00e8me a eu peu d'impact sur le d\u00e9veloppement de l'API, il est davantage li\u00e9 \u00e0 la compr\u00e9hension de sa demande et de sa fonctionnalit\u00e9.<\/li>\n<\/ol>\n

    <\/p>\n

    Tentative num\u00e9ro deux : REST API<\/h2>\n

    \nEn 2010, nous avons tent\u00e9 de construire un syst\u00e8me d'\u00e9change avec la comptabilit\u00e9 en ligne \u2014 BoukhSoft. Cela n'a pas d\u00e9coll\u00e9. Cependant, au cours de l'int\u00e9gration, nous avons d\u00e9velopp\u00e9 une API compl\u00e8te : un service REST d'\u00e9change, o\u00f9 il n'y avait pas de libert\u00e9s telles que les appels RPC. Toute communication avec l'API a \u00e9t\u00e9 r\u00e9duite \u00e0 un mode standard pour REST : le nom de l'entit\u00e9 est contenu dans la cha\u00eene de requ\u00eate, et l'op\u00e9ration qui s'applique \u00e0 elle est d\u00e9finie \u00e0 l'aide de la m\u00e9thode HTTP. Nous avons ajout\u00e9 un filtrage bas\u00e9 sur le moment de la mise \u00e0 jour des entit\u00e9s, et les utilisateurs ont eu la possibilit\u00e9 de construire une r\u00e9plication avec leurs syst\u00e8mes.<\/p>\n

    La m\u00eame ann\u00e9e, nous avons introduit une API pour l'exportation des stocks et des articles. Les utilisateurs ont d\u00e9sormais acc\u00e8s via l'API aux parties les plus pr\u00e9cieuses du syst\u00e8me \u2014 l'\u00e9change de documents primaires et les donn\u00e9es de calcul concernant les stocks et le co\u00fbt des articles.<\/p>\n

    En d\u00e9cembre 2015, RetailCRM a publi\u00e9 sa premi\u00e8re biblioth\u00e8que tierce pour acc\u00e9der \u00e0 notre API. Elle a \u00e9t\u00e9 assez activement utilis\u00e9e, tandis que la popularit\u00e9 du service en g\u00e9n\u00e9ral augmentait, la charge sur l'API augmentait plus rapidement que celle sur l'interface web. Un jour, cette croissance s'est transform\u00e9e en un saut de charge. <\/p>\n

    \"APIs
    \n
    \n\"APIs
    \n
    \nEt ce saut, que montre la fl\u00e8che \u00e0 gauche, a compl\u00e8tement stup\u00e9fi\u00e9 le serveur qui servait notre API. Nous avons pass\u00e9 une semaine \u00e0 examiner quelle charge \u00e9tait r\u00e9ellement g\u00e9n\u00e9r\u00e9e. Il s'est av\u00e9r\u00e9 qu'il s'agissait de ces m\u00eames requ\u00eates, traduites vers notre API depuis les fronts des clients. Environ 50 clients ont consomm\u00e9 toute la charge. C'est \u00e0 ce moment-l\u00e0 que nous avons compris une de nos erreurs \u2014 l'absence totale de limites. <\/p>\n

    Au final, nous avons introduit une limite sur le nombre de requ\u00eates simultan\u00e9es. Avec un seul compte, il n'\u00e9tait plus possible d'ouvrir plus de deux requ\u00eates en m\u00eame temps. Cela suffit pour fonctionner en mode de r\u00e9plication pour l'\u00e9change de donn\u00e9es en mode batch. Quant \u00e0 ceux qui voulaient nous utiliser comme backend, ils ont d\u00fb se conformer davantage aux tarifs, car nous avons introduit dans leurs moyens logiciels le travail sur plusieurs comptes.<\/p>\n

    Mettre en ordre<\/h2>\n

    \nDepuis 2014, la demande pour l'API existante est devenue une partie importante des affaires, et la propre API g\u00e9n\u00e9rait le plus grand volume de donn\u00e9es dans les \u00e9changes avec les clients. En 2015, nous avons lanc\u00e9 un projet de mise en ordre de l'API. Nous avons choisi le format JSON au lieu de XML et avons commenc\u00e9 \u00e0 le construire en fonction des caract\u00e9ristiques que nous avons identifi\u00e9es lors de la mise en \u0153uvre de la version pr\u00e9c\u00e9dente :<\/p>\n

      \n
    1. La possibilit\u00e9 de g\u00e9rer les versions. La versionnage permet de d\u00e9velopper une nouvelle version sans affecter l'application existante et sans perturber le travail des utilisateurs. <\/li>\n
    2. La possibilit\u00e9 pour l'utilisateur de voir les m\u00e9tadonn\u00e9es dans la r\u00e9ponse m\u00eame qu'il re\u00e7oit.<\/li>\n
    3. La possibilit\u00e9 d'\u00e9changer de gros documents. Si nous traitons un document contenant plus de 4-5 mille lignes, cela devient un probl\u00e8me pour le serveur : une transaction longue, une longue requ\u00eate http. Nous avons construit un m\u00e9canisme sp\u00e9cial permettant de mettre \u00e0 jour le document par parties et de g\u00e9rer les \u00e9l\u00e9ments individuels de ce document, en les envoyant au serveur.<\/li>\n
    4. Les outils de r\u00e9plication \u00e9taient d\u00e9j\u00e0 pr\u00e9sents dans la version pr\u00e9c\u00e9dente.<\/li>\n
    5. Limites de charge - h\u00e9ritage des erreurs commises dans la version pr\u00e9c\u00e9dente. Des limites ont \u00e9t\u00e9 mises en place concernant le nombre de requ\u00eates par p\u00e9riode de temps, le nombre de requ\u00eates parall\u00e8les et les requ\u00eates provenant d'une seule adresse IP.<\/li>\n<\/ol>\n

      \nDepuis, nous avons publi\u00e9 deux versions mineures de l'API et lanc\u00e9 plusieurs API sp\u00e9cialis\u00e9es, mais notre approche est rest\u00e9e essentiellement la m\u00eame. Le format d'\u00e9change mis \u00e0 jour et la nouvelle architecture ont permis de corriger les d\u00e9fauts de l'API beaucoup plus rapidement.<\/p>\n

      L'API de MonStock aujourd'hui<\/h2>\n

      \nAujourd'hui, l'API de MonStock r\u00e9sout de nombreuses t\u00e2ches :<\/p>\n