API écrite - XML ​​cassé (deux)

La première API MyStore est apparue il y a 10 ans. Pendant tout ce temps, nous travaillons sur des versions existantes de l'API et en développons de nouvelles. Et plusieurs versions de l'API ont déjà été enterrées.

Cet article aura beaucoup de choses: comment créer l'API, pourquoi le service cloud en a besoin, ce qui donne aux utilisateurs quel rake nous avons réussi à utiliser et ce que nous voulons faire ensuite.

Je m'appelle Oleg Alekseev oalexeev , je suis le directeur technique et co-fondateur de MySklad.

Pourquoi créer une API pour un service

Nos clients, qui sont des dizaines de milliers d'entrepreneurs, utilisent activement les solutions cloud: banque, boutiques en ligne, comptabilité produit, CRM. Connecté à un - et c'est déjà difficile de s'arrêter. Et maintenant, le cinquième, huitième, dixième service facilite le travail de l'entrepreneur, mais les utilisateurs transfèrent manuellement les données entre ces services cloud. Le travail se transforme en cauchemar.

La solution évidente est de donner aux utilisateurs la possibilité de transférer des données entre les services cloud. Par exemple, importez et exportez des données sous forme de fichiers, qui peuvent ensuite être téléchargés vers le service souhaité. Les fichiers sont généralement modifiés au format de chaque service. Il s'agit d'un travail manuel plus ou moins simple, mais avec l'augmentation du nombre de ces services, il devient plus difficile de l'exécuter.

Par conséquent, l'étape suivante est l'API. Avec lui, un service cloud bénéficie de la connexion de plusieurs services en un seul point. L'émergence d'un tel écosystème attire de nouveaux clients grâce à des opportunités supplémentaires. Un produit doté de nouvelles fonctionnalités devient plus rentable et utile.

Si vous créez vos propres interfaces de programme, cela attire des vendeurs tiers sous la forme de programmeurs qui connaissent votre produit grâce à l'API. Ils commencent à construire des solutions basées sur l'API proposée et gagnent de l'argent en automatisant les tâches de leurs clients.

Le système comptable de MyStore est construit sur des processus simples. L'essentiel est de travailler avec des documents primaires, la capacité d'accepter et d'expédier des marchandises, et de recevoir des rapports d'activité sur la base du primaire. Il y a aussi le transfert de données, par exemple, vers la comptabilité cloud, et leur réception par les systèmes bancaires ou les points de vente. Nous travaillons également avec des boutiques en ligne: nous recevons des informations sur les marchandises et envoyons des données sur les soldes.

Première API MyStore

Au cours de 10 années de travail de MyStore avec l'API, nous avons acquis toutes sortes d'intégrations qui vous permettent d'échanger des données, de travailler avec des banques, de payer et d'utiliser la téléphonie externe.

La première année, nous avons permis de télécharger toutes les données au format XML. Ensuite, il était beaucoup plus compréhensible et familier pour les utilisateurs de garder les données hors ligne, et non dans une sorte de cloud, et nous leur avons donné ceci. Le déchargement a commencé par une exportation manuelle depuis l'interface. Autrement dit, l'API n'a pas encore pu être appelée.

Ensuite, nous avons commencé à coopérer avec Rusagro - ils utilisaient déjà l'ERP "adulte" pour planifier la production et les ventes, mais le chargement des voitures dans les usines a été automatisé à MySklad. Nous avons donc eu les premiers rudiments de cette API: l'échange entre notre service et l'ERP a eu lieu en envoyant un fichier volumineux avec des données pour tous types de documents.

C'est une bonne option pour l'échange de données par lots, mais avec les documents, ils devaient transférer leurs dépendances: informations sur les marchandises, les entrepreneurs et les entrepôts. Une telle décharge n'est pas si difficile à générer lors de l'exportation, mais elle est plutôt difficile à démonter lors de l'importation, car toutes les informations sont réunies dans un seul paquet: à la fois sur les nouveaux documents et sur les documents existants.

La première API XML n'a pas duré longtemps - deux ans plus tard, nous avons commencé à la reconstruire. Même au début de son travail, nous avons fait plusieurs erreurs lors de la construction de l'interface logicielle.


Comment l'API XML a été créée: une illustration d'un de nos architectes. Soit dit en passant, attendez ses articles.

Voici nos principales erreurs:

1. Le balisage JAXB a été effectué directement sur les beans entité. Nous utilisons Hibernate pour communiquer avec la base de données et le balisage JAXB a été effectué sur les mêmes beans. Cette erreur est survenue presque immédiatement: toute mise à jour de la structure de données a conduit à la nécessité de prévenir de toute urgence tous ceux qui utilisent l'API, ou de construire des béquilles qui garantiraient la compatibilité avec la structure de données précédente.
2. L'API s'est développée comme une sorte d'ajout, et au départ, nous n'avons pas déterminé quelle partie du produit elle constituait. Nous n'avons même pas pensé à savoir si l'API était quelque chose d'important, s'il était nécessaire de maintenir la compatibilité descendante pour ses premiers clients. À un moment donné, le nombre d'utilisateurs d'API était d'environ 5% du petit nombre total, et aucune attention n'a été accordée à eux. Le filtrage universel réalisé en temps voulu nous a conduit à nous utiliser comme backend. Ce filtrage n'était pas du tout GraphQL, mais quelque chose comme ça - il a fonctionné à travers de nombreux paramètres de chaîne de requête. Avec un outil aussi puissant, il était difficile pour les utilisateurs de résister, et les demandes nous étaient transférées afin qu'elles soient envoyées directement depuis l'interface utilisateur de leurs boutiques en ligne. La situation a été une surprise désagréable, car la fourniture d'un tel service devrait nécessiter une tarification différente et une compréhension différente de l'API elle-même en tant que produit.
3. Étant donné que l'API ne s'est pas développée en tant que produit principal, la documentation de l'API a été produite et publiée selon le principe résiduel - par rétro-ingénierie. Cette méthode semble assez simple et pratique, mais contraire au travail à contrat. C'est quand il y a un certain composant avec un schéma de travail prédéfini. Le développeur le met en œuvre conformément à ce schéma et à cette tâche, le composant est testé, le client reçoit un produit qui correspond à l'idée de l'analyste. La rétro-ingénierie, d'autre part, lance un produit qui existe simplement: avec des béquilles, des solutions étranges et des vélos au lieu des fonctionnalités nécessaires.
4. L'ensemble du flux de demandes provenant de l'API n'a pu être analysé que dans un journal ou un serveur d'applications Nginx. Cela ne nous a pas permis d'isoler les sujets, sauf peut-être de les diviser par utilisateurs et abonnés. S'il n'est pas possible de réglementer l'enregistrement de l'application ou des clients, il devient impossible d'analyser la situation. Ce problème a eu le moins d'impact sur le développement de l'API, il s'agit plutôt de comprendre sa pertinence et ses fonctionnalités.

Tentative numéro deux: API REST

En 2010, nous avons essayé de construire un système d'échange avec comptabilité en ligne - BukhSoft. N'a pas décollé. Mais dans le processus d'intégration, une API à part entière est apparue: un service d'échange REST, où il n'y avait pas de libertés comme les appels aux opérations sous forme d'appels RPC. Toutes les communications avec l'API ont été ramenées à un mode standard de repos: la chaîne de requête contient le nom de l'entité et l'opération qui est effectuée avec elle est définie à l'aide de la méthode http. Nous avons ajouté le filtrage au moment de la mise à jour des entités, et les utilisateurs ont désormais la possibilité de créer une réplication avec leurs systèmes.

La même année, une API est apparue pour le déchargement des soldes d'entrepôt et de marchandises. Les parties les plus précieuses du système sont devenues disponibles pour les utilisateurs via l'API - l'échange de documents primaires et de données estimées sur les soldes et le coût des marchandises.

En décembre 2015, RetailCRM a publié la première bibliothèque tierce à accéder à notre API. Ils ont commencé à l'utiliser assez activement, alors que la popularité du service dans son ensemble augmentait, la charge sur l'API augmentait plus vite que la charge sur l'interface Web. Une fois, la croissance s'est transformée en un saut de charge.





Et ce saut, qui est indiqué par la flèche à gauche, a conduit à la stupéfaction totale du serveur desservant notre API. Pendant une semaine, nous avons compris ce que génère exactement cette charge. Il s'est avéré que ce sont les demandes mêmes diffusées à notre API depuis les fronts des clients. Une cinquantaine de clients ont tout mangé. C'est alors que nous avons réalisé l'une de nos erreurs - l'absence totale de limites.

En conséquence, nous avons introduit une limite sur le nombre de demandes simultanées. À partir d'un compte, il est devenu possible d'ouvrir simultanément pas plus de deux demandes. Cela suffit pour travailler en mode réplication pour échanger des données en mode batch. Et ceux qui voulaient nous utiliser comme backend, à partir de ce moment, ont été obligés de se conformer davantage aux tarifs, car ils ont introduit des travaux sur plusieurs comptes dans leur logiciel.

Ranger

Depuis 2014, la demande pour l'API existante est devenue une partie importante de l'entreprise, et l'API elle-même a généré la plus grande quantité de données lors de l'échange de données avec les clients. En 2015, nous avons lancé un projet de nettoyage de l'API. Nous avons choisi JSON au lieu de XML comme format et avons commencé à le construire sur la base des fonctionnalités révélées lors de la mise en œuvre de la version précédente:

1. Capacité à gérer les versions. Le contrôle de version vous permet de développer une nouvelle version sans affecter une application existante et sans perturber les utilisateurs.
2. La possibilité pour l'utilisateur de voir les métadonnées dans la réponse qu'il reçoit.
3. La possibilité d'échanger des documents volumineux. Si nous traitons un document avec un nombre de positions supérieur à 4-5 000, cela devient un problème pour le serveur: une longue transaction, une longue requête http. Nous avons construit un mécanisme spécial qui vous permet de mettre à jour le document en plusieurs parties et de gérer les positions individuelles de ce document en les envoyant au serveur.
4. Outils de réplication - étaient dans la version précédente.
5. Les limites de charge sont comme l'héritage du râteau qui a été utilisé dans la version précédente. Introduit des limites sur le nombre de demandes dans une période de temps, le nombre de demandes simultanées et les demandes d'une adresse IP.

À partir de ce moment, nous avons publié deux versions mineures de l'API et lancé plusieurs API spécialisées, mais en général, l'approche est restée inchangée. Un format d'échange mis à jour et une nouvelle architecture ont permis de corriger beaucoup plus rapidement les lacunes de l'API.

API MyStore aujourd'hui

Aujourd'hui, l'API MyStore résout de nombreux problèmes:

• échange de données avec les magasins en ligne, les systèmes comptables, les banques;
• recevoir des données de règlement, des rapports;
• utiliser comme backend pour les applications client - nos applications mobiles et nos caisses de bureau fonctionnent via l'API
• envoyer des notifications sur les modifications de données dans MyStore - webhooks;
• téléphonie;
• systèmes de fidélité.

Basé sur l'API, notre PDG rhinocéros Askar Rakhimberdiev a écrit en quatre heures un robot télégramme qui tire le reste à travers l'API: github.com/arahimberdiev/com-lognex-telegram-moysklad-stock

Maintenant des chiffres secs.

Voici nos statistiques pour l'ancienne API REST:

• 400 entreprises;
• 600 utilisateurs;
• 2 millions de demandes par jour;
• 200 Go / jour de trafic sortant.

Et voici à quoi nous sommes arrivés avec toutes les API MyStore:

• plus de 70 intégrations (certaines d'entre elles peuvent être trouvées ici www.moysklad.ru/integratsii );
• 8500 entreprises;
• 12 000 utilisateurs;
• 46 millions de demandes par jour;
• 2 To / jour de trafic sortant.

Et ensuite

Les plans de développement d'API sont en discussion active. Nous essayons de prendre en compte l'expérience d'exploitation que les utilisateurs nous fournissent. Pas toujours et tout ne se fait pas tout de suite, mais pas loin se trouve une nouvelle version de l'API avec des métadonnées plus pratiques et une structure moins lourde, OAuth pour l'authentification, une API pour les applications intégrées à l'interface.

Vous pouvez suivre l'actualité sur un site spécial pour les développeurs d'intégration avec MySklad: dev.moysklad.ru .