Die erste API von MoegoSkłada ist vor 10 Jahren erschienen. Seitdem arbeiten wir an den bestehenden API-Versionen und entwickeln neue. Einige Versionen der API wurden bereits eingestellt.
In diesem Artikel gibt es viel zu entdecken: wie die API entwickelt wurde, warum sie für unseren Cloud-Service wichtig ist, welche Vorteile sie den Nutzern bietet, welche Herausforderungen wir gemeistert haben und was wir als Nächstes planen.
Mein Name ist Oleg Alexeev , ich bin technischer Direktor und Mitgründer von MoegoSkłada.
Warum eine API für den Service erstellen?
Unsere Kunden, darunter Zehntausende von Unternehmern, nutzen aktiv Cloud-Lösungen: Banking, Online-Shops, Warenwirtschaft und CRM. Einmal angeschlossen — und schon ist es schwer, wieder aufzuhören. Und jetzt bieten der fünfte, achte, zehnte Dienst eine Erleichterung für die Unternehmer, aber die Daten zwischen diesen Cloud-Diensten werden manuell übertragen. Die Arbeit verwandelt sich in einen Albtraum.
Eine offensichtliche Lösung besteht darin, den Nutzern die Möglichkeit zu geben, Daten zwischen Cloud-Diensten zu übertragen. Zum Beispiel können Daten als Dateien importiert und exportiert werden, die anschließend in den gewünschten Dienst hochgeladen werden. Die Dateien müssen normalerweise an das Format jedes Dienstes angepasst werden. Das ist mehr oder weniger einfache Handarbeit, wird aber zunehmend komplizierter, je mehr dieser Dienste hinzukommen.
Der nächste Schritt ist daher die API. Mit ihr profitiert der Cloud-Dienst davon, mehrere Dienste an einem Punkt zu verknüpfen. Das Auftreten eines solchen Ökosystems zieht neue Kunden an, da zusätzliche Funktionen zur Verfügung stehen. Ein Produkt mit neuen Funktionalitäten wird dadurch attraktiver und nützlicher.
Wenn eigene Programmierschnittstellen erstellt werden, zieht das Drittanbieter wie Programmierer an, die durch die API auf Ihr Produkt aufmerksam werden. Sie beginnen, Lösungen auf Basis der angebotenen API zu entwickeln und verdienen Geld mit der Automatisierung der Aufgaben ihrer Kunden.
Das Buchhaltungssystem von МоегоСклада basiert auf einfachen Prozessen. Das Wichtigste ist die Arbeit mit Primärdokumenten, die Möglichkeit, Waren anzunehmen und auszuliefern, sowie auf Basis der Primärdaten Unternehmensberichte zu erstellen. Zudem gibt es die Datenübertragung, beispielsweise an cloudbasierte Buchhaltungssysteme, und die Datenabfrage aus Bankensystemen oder Einzelhandelsstellen. Außerdem arbeiten wir mit Online-Shops: Wir erhalten Informationen über Produkte und senden Daten über den Lagerbestand.
Die erste API von МоегоСклада
Nach 10 Jahren Erfahrung mit der API von МоегоСклада haben wir zahlreiche Integrationen entwickelt, die einen Datenaustausch ermöglichen, mit Banken arbeiten, Zahlungen abwickeln und externe Telefonie nutzen.
Im ersten Jahr haben wir die Möglichkeit geschaffen, beliebige Daten im XML-Format zu exportieren. Damals war es für die Benutzer viel verständlicher und gewohnter, Daten offline zu halten, anstatt in einer Cloud, und wir haben ihnen diese Option gegeben. Der Export wurde manuell über die Benutzeroberfläche gestartet. Man konnte also noch nicht wirklich von einer API sprechen.
Zu dieser Zeit begannen wir die Zusammenarbeit mit der Firma Rusagro – sie nutzten bereits ein „erwachsenes“ ERP-System zur Produktions- und Vertriebsplanung, während die Beladung der Wagen in den Werken in МоемСкладе automatisiert wurde. So entstanden die ersten Ansätze einer echten API: der Austausch zwischen unserem Service und der ERP erfolgte durch den Versand einer großen Datei mit Daten zu allen Dokumenttypen.
Das ist eine annehmbare Option für den batchweisen Datenaustausch, aber zusammen mit den Dokumenten musste man auch deren Abhängigkeiten übermitteln: Informationen zu Produkten, Geschäftspartnern und Lagern. So einen Sammelsurium zu generieren, ist beim Export nicht so schwer, aber beim Import ziemlich schwierig, da in einem Paket alle Informationen ankommen: sowohl über neue Dokumente als auch über bereits vorhandene.
Die erste XML-API hatte eine kurze Lebensdauer – nach zwei Jahren begannen wir mit ihrer Umgestaltung. Schon zu Beginn ihrer Implementierung machten wir einige Fehler beim Aufbau der Programmierschnittstelle.
Wie die XML-API erstellt wurde: eine Illustration von einem unserer Architekten. Übrigens, erwarten Sie seine Artikel.
Hier sind unsere Hauptfehler:
- Die JAXB-Markierung wurde direkt auf die Entity Beans angewendet. Für die Kommunikation mit der Datenbank verwenden wir Hibernate, und auch für diese Beans wurde die JAXB-Markierung erstellt. Dieser Fehler trat nahezu sofort auf: Jede Aktualisierung der Datenstruktur erforderte entweder eine sofortige Benachrichtigung aller, die die API nutzen, oder das Erstellen von Workarounds, um die Kompatibilität mit der vorherigen Datenstruktur sicherzustellen.
- Die API entwickelte sich zunächst als Ergänzung, und wir haben nicht klar definiert, welchen Teil des Produkts sie ausmacht. Wir haben auch nicht darüber nachgedacht, ob die API wirklich wichtig ist oder ob wir die Abwärtskompatibilität für unsere ersten Kunden aufrechterhalten sollten. Für eine Zeit lang machte die Anzahl der API-Nutzer etwa 5 % der insgesamt kleinen Nutzerbasis aus, was dazu führte, dass sie nicht beachtet wurden. Die damals implementierte universelle Filterung führte dazu, dass wir als Backend genutzt wurden. Diese Filterung war zwar nicht ganz GraphQL, aber eine Art davon – sie funktionierte über eine Vielzahl von Abfrageparametern. Mit einem so mächtigen Tool fiel es den Nutzern schwer, darauf zu verzichten, und die Anfragen wurden direkt von den UIs ihrer Online-Shops an uns weitergeleitet. Diese Situation stellte sich als unangenehme Überraschung heraus, da die Bereitstellung eines solchen Services eine andere Preisgestaltung und ein grundsätzliches anderes Verständnis der API als Produkt erfordern sollte.
- Da sich die API nicht als Hauptprodukt entwickelt hat, wurde die Dokumentation zur API nach dem Prinzip der Restproduktion erstellt und veröffentlicht — durch Reverse Engineering. Dieser Ansatz mag einfach und praktisch erscheinen, widerspricht jedoch dem vertraglichen Arbeitsprozess. Es gibt einen bestimmten Baustein mit einer festgelegten Arbeitsweise. Der Entwickler setzt ihn gemäß dieser Arbeitsweise und den Anforderungen um, der Baustein wird getestet, und der Kunde erhält ein Produkt, das den Vorstellungen des Analysten entspricht. Reverse Engineering hingegen bringt ein Produkt auf den Markt, das einfach vorhanden ist: mit provisorischen Lösungen, seltsamen Entscheidungen und umständlichen Ansätzen anstelle der erforderlichen Funktionalität.
- Der gesamte Anfragefluss, der über die API kam, konnte höchstens als Nginx- oder Anwendungserver-Protokoll analysiert werden. Das erlaubte es nicht, Themenbereiche herauszustellen, es sei denn, man hätte dies nach Benutzern und Abonnenten unterteilt. Wenn es keine Möglichkeit gibt, die Registrierung der Anwendung oder der Kunden zu steuern, wird es unmöglich, die Situation zu analysieren. Dieses Problem hatte nur einen minimalen Einfluss auf die Entwicklung der API; es geht vielmehr um das Verständnis ihrer Nachfrage und Funktionsfülle.
Versuch Nummer zwei: REST API
Im Jahr 2010 versuchten wir, ein Austauschsystem mit einer Online-Buchhaltungssoftware – BuchSoft – aufzubauen. Das hat nicht geklappt. Doch im Zuge der Integration entstand eine vollwertige API: ein REST-Datenaustauschdienst, der keine Freiheiten wie RPC-Anrufe für Operationen enthielt. Die gesamte Kommunikation mit der API wurde auf den standardmäßigen REST-Modus reduziert: In der Anfragezeile befindet sich der Name der Entität, und die Operation, die mit ihr durchgeführt wird, wird durch die HTTP-Methode definiert. Wir haben die Möglichkeit zur Filterung nach dem Zeitpunkt der Aktualisierung von Entitäten hinzugefügt, wodurch Benutzer die Möglichkeit erhielten, Replikationen mit ihren eigenen Systemen aufzubauen.
Im selben Jahr wurde die API für den Export von Lager- und Warenbeständen eingeführt. Über die API wurden den Nutzern die wertvollsten Teile des Systems zugänglich gemacht – der Austausch von Primärdokumenten und die Berechnung von Beständen sowie den Kosten der Waren.
Im Dezember 2015 veröffentlichte RetailCRM die erste externe Bibliothek für den Zugriff auf unsere API. Diese wurde ziemlich aktiv genutzt, während die Popularität des Services insgesamt wuchs, und die Last auf der API schneller stieg als die auf der Web-Oberfläche. Eines Tages verwandelte sich das Wachstum in einen sprunghaften Anstieg der Last.
Und dieser Anstieg, auf den der Zeiger links hinweist, versetzte den Server, der unsere API bedient, in völliges Staunen. Eine Woche lang haben wir untersucht, was genau diese Last erzeugt. Es stellte sich heraus, dass es die Anfragen waren, die von den Frontends unserer Kunden an unsere API gesendet wurden. Rund 50 Kunden waren dafür verantwortlich. Hier wurde uns einer unserer Fehler klar – das vollständige Fehlen von Limits.
Wir haben schließlich eine Begrenzung für die Anzahl gleichzeitiger Anfragen eingeführt. Von einem Konto aus können nun nicht mehr als zwei Anfragen gleichzeitig geöffnet werden. Das reicht für den Betrieb im Replikationsmodus aus, um Daten im Batch-Modus auszutauschen. Wer uns als Backend nutzen wollte, musste von diesem Zeitpunkt an stärker auf die Tarifbedingungen achten, da die Nutzung mehrerer Konten in ihren Softwaretools eingeführt wurde.
Organisieren wir es neu
Bereits seit 2014 ist die Nachfrage nach der verfügbaren API ein wichtiger Bestandteil des Geschäfts, und die API selbst generierte das größte Datenvolumen im Austausch mit Kunden. Im Jahr 2015 haben wir ein Projekt zur Optimierung der API gestartet. Wir wählten das JSON-Format anstelle von XML und begannen, es basierend auf den Merkmalen zu gestalten, die wir bei der Implementierung der vorherigen Version festgestellt hatten:
- Möglichkeit zur Versionsverwaltung. Die Versionierung ermöglicht die Entwicklung einer neuen Version, ohne die bestehende Anwendung zu beeinträchtigen und den Betrieb der Nutzer zu stören.
- Möglichkeit, dass der Benutzer Metadaten in der Antwort sieht, die er erhält.
- Die Möglichkeit, große Dokumente auszutauschen. Wenn wir ein Dokument mit mehr als 4-5 Tausend Positionen verarbeiten, wird es für den Server problematisch: lange Transaktionen und lange HTTP-Anfragen. Wir haben einen speziellen Mechanismus entwickelt, der es ermöglicht, das Dokument in Teilen zu aktualisieren und einzelne Positionen zu verwalten, indem wir sie an den Server senden.
- Replikationswerkzeuge – diese gab es auch in der vorherigen Version.
- Lastgrenzen – ein Erbe der Probleme, die in der vorherigen Version auftraten. Wir haben Grenzen für die Anzahl der Anfragen innerhalb eines Zeitraums, die Anzahl der parallelen Anfragen und Anfragen von einer IP-Adresse eingeführt.
Seitdem haben wir zwei kleinere API-Versionen veröffentlicht und mehrere spezialisierte APIs gestartet, aber der Ansatz blieb insgesamt unverändert. Das aktualisierte Austauschformat und die neue Architektur haben es uns ermöglicht, Mängel im API viel schneller zu beheben.
Das API von MoегоСклада heute
Heute löst das API von MoегоСклада viele Aufgaben:
- Daten Austausch mit Onlineshops, Buchhaltungssystemen, Banken;
- Erhalt von Berechnungsdaten, Berichten;
- Nutzung als Backend für Kundenanwendungen – unsere mobilen Apps und die Desktop-Kasse arbeiten über die API.
- Versand von Benachrichtigungen über Datenänderungen in MeinemLager – Webhooks;
- Telefonie;
- Loyalitätssysteme.
Basierend auf der API hat unser Geschäftsführer Askar Rakhimberdiev in vier Stunden einen Telegram-Bot geschrieben, der über die API die Bestände abruft:
Jetzt zu den harten Zahlen.
Hier sind unsere Statistiken zum alten REST API:
- 400 Unternehmen;
- 600 Benutzer;
- 2 Millionen Anfragen pro Tag;
- 200 GB/Tag ausgehender Traffic.
Und hier ist, wo wir mit allen APIs von MeinemLager angekommen sind:
- über 70 Integrationen (ein Teil davon kann hier eingesehen werden );
- 8500 Unternehmen;
- 12.000 Benutzer;
- 46 Millionen Anfragen pro Tag;
- 2 TB/Tag ausgehender Traffic.
Was kommt als Nächstes
Die Pläne zur Weiterentwicklung der API sind aktiv in Diskussion. Wir bemühen uns, die Erfahrungen von Nutzern zu berücksichtigen. Es gelingt nicht immer, alles sofort umzusetzen, aber die neue API-Version mit benutzerfreundlicheren Metadaten und einer weniger komplexen Struktur, OAuth für die Authentifizierung und APIs für integrierte Anwendungen steht kurz bevor.
Neuigkeiten können auf der speziellen Website für Entwickler von Integrationen mit МойСклад verfolgt werden: .
Quelle: habr.com
