Schrieb API - brach XML (zwei)

Die erste MyStore-API wurde vor 10 Jahren veröffentlicht. Während dieser ganzen Zeit arbeiten wir an vorhandenen Versionen der API und entwickeln neue. Und mehrere Versionen der API wurden bereits begraben.

Dieser Artikel enthält viele Informationen: Wie wird die API erstellt, warum wird der Cloud-Dienst benötigt, was gibt den Benutzern, auf welchen Rake wir getreten sind und was wir als Nächstes tun möchten.

Mein Name ist Oleg Alekseev oalexeev , ich bin der technische Direktor und Mitbegründer von MySklad.

Warum eine API für einen Dienst erstellen?

Unsere Kunden, die Zehntausende von Unternehmern sind, nutzen aktiv Cloud-Lösungen: Banking, Online-Shops, Produktbuchhaltung, CRM. Verbunden mit einem - und es ist schon schwierig aufzuhören. Und jetzt erleichtert der fünfte, achte und zehnte Dienst die Arbeit des Unternehmers, aber Benutzer übertragen Daten manuell zwischen diesen Cloud-Diensten. Arbeit wird zum Albtraum.

Die naheliegende Lösung besteht darin, Benutzern die Möglichkeit zu geben, Daten zwischen Cloud-Diensten zu übertragen. Importieren und exportieren Sie beispielsweise Daten als Dateien, die dann auf den gewünschten Dienst heruntergeladen werden können. Dateien werden normalerweise in das Format jedes Dienstes geändert. Dies ist mehr oder weniger einfache manuelle Arbeit, aber mit zunehmender Anzahl dieser Dienste wird es schwieriger, sie auszuführen.

Daher ist der nächste Schritt die API. Damit profitiert ein Cloud-Dienst von der Verbindung mehrerer Dienste an einem Punkt. Die Entstehung eines solchen Ökosystems zieht aufgrund zusätzlicher Möglichkeiten neue Kunden an. Ein Produkt mit neuen Funktionen wird rentabler und nützlicher.

Wenn Sie Ihre eigenen Programmschnittstellen erstellen, zieht dies Drittanbieter in Form von Programmierern an, die dank der API über Ihr Produkt Bescheid wissen. Sie beginnen, Lösungen basierend auf der vorgeschlagenen API zu entwickeln und verdienen Geld, indem sie die Aufgaben ihrer Kunden automatisieren.

Das Buchhaltungssystem von MyStore basiert auf einfachen Prozessen. Die Hauptsache ist die Arbeit mit Primärdokumenten, die Fähigkeit, Waren anzunehmen und zu versenden und Geschäftsberichte auf der Grundlage der Primärdokumente zu erhalten. Es gibt auch Datenübertragungen, zum Beispiel in die Cloud-Buchhaltung, und deren Empfang von Bankensystemen oder Einzelhandelsgeschäften. Wir arbeiten auch mit Online-Shops zusammen: Wir erhalten Informationen über Waren und senden Daten über Salden.

Erste MyStore-API

In über 10 Jahren Arbeit von MyStore mit der API haben wir alle Arten von Integrationen erworben, mit denen Sie Daten austauschen, mit Banken zusammenarbeiten, Zahlungen tätigen und externe Telefonie nutzen können.

Im ersten Jahr haben wir es möglich gemacht, Daten im XML-Format hochzuladen. Dann war es für Benutzer viel verständlicher und vertrauter, die Daten offline und nicht in einer Art Cloud zu halten, und wir gaben ihnen dies. Das Entladen wurde durch manuellen Export von der Schnittstelle gestartet. Das heißt, die API konnte noch nicht aufgerufen werden.

Dann begannen wir mit Rusagro zusammenzuarbeiten - sie nutzten bereits das ERP für Erwachsene, um Produktion und Verkauf zu planen, aber das Laden von Autos in den Werken wurde in MySklad automatisiert. So erhielten wir die ersten Grundlagen dieser API: Der Austausch zwischen unserem Service und ERP erfolgte durch Senden einer großen Datei mit Daten für alle Arten von Dokumenten.

Dies ist eine gute Option für den Batch-Datenaustausch, aber zusammen mit den Dokumenten mussten sie ihre Abhängigkeiten übertragen: Informationen über Waren, Auftragnehmer und Lager. Eine solche Deponie ist beim Export nicht so schwer zu erzeugen, beim Import jedoch nur schwer zu zerlegen, da alle Informationen in einem Paket enthalten sind: sowohl über neue als auch über bestehende Dokumente.

Die erste XML-API hielt nicht lange an - zwei Jahre später begannen wir, sie neu zu erstellen. Schon zu Beginn seiner Arbeit haben wir beim Erstellen der Software-Schnittstelle einige Fehler gemacht.


Wie die XML-API erstellt wurde: eine Illustration von einem unserer Architekten. Warten Sie übrigens auf seine Artikel.

Hier sind unsere Hauptfehler:

1. JAXB-Markup wurde direkt für Entity-Beans durchgeführt. Wir verwenden den Ruhezustand, um mit der Datenbank zu kommunizieren, und das JAXB-Markup wurde für dieselben Beans erstellt. Dieser Fehler trat fast sofort auf: Jede Aktualisierung der Datenstruktur führte dazu, dass jeder, der die API verwendet, dringend benachrichtigt oder Krücken erstellt werden mussten, um die Kompatibilität mit der vorherigen Datenstruktur sicherzustellen.
2. Die API wuchs als eine Art Ergänzung, und anfangs haben wir nicht festgestellt, welchen Teil des Produkts sie ausmacht. Wir haben nicht einmal darüber nachgedacht, ob die API etwas Wichtiges ist, ob es notwendig ist, die Abwärtskompatibilität für die ersten Kunden aufrechtzuerhalten. Irgendwann betrug die Anzahl der API-Benutzer etwa 5% der gesamten kleinen Anzahl, und ihnen wurde keine Aufmerksamkeit geschenkt. Die zu gegebener Zeit vorgenommene universelle Filterung hat dazu geführt, dass wir als Backend verwendet werden. Diese Filterung war überhaupt nicht GraphQL, aber so ähnlich - sie funktionierte durch viele Abfragezeichenfolgenparameter. Mit einem so leistungsstarken Tool war es für Benutzer schwierig, Widerstand zu leisten, und Anfragen wurden an uns weitergeleitet, sodass sie direkt von der Benutzeroberfläche ihrer Online-Shops gesendet wurden. Die Situation war eine unangenehme Überraschung, da die Bereitstellung eines solchen Dienstes unterschiedliche Gebühren und ein anderes Verständnis der API selbst als Produkt erfordern sollte.
3. Aufgrund der Tatsache, dass sich die API nicht als Hauptprodukt entwickelt hat, wurde die API-Dokumentation nach dem Restprinzip erstellt und veröffentlicht - durch Reverse Engineering. Dieser Weg scheint recht einfach und bequem zu sein, widerspricht jedoch der Vertragsarbeit. Dies ist der Fall, wenn eine bestimmte Komponente mit einem vordefinierten Arbeitsschema vorhanden ist. Der Entwickler implementiert es gemäß diesem Schema und dieser Aufgabe, die Komponente wird getestet, der Kunde erhält ein Produkt, das der Idee des Analysten entspricht. Reverse Engineering hingegen wirft ein Produkt auf, das einfach existiert: mit Krücken, seltsamen Lösungen und Fahrrädern anstelle der erforderlichen Funktionalität.
4. Der gesamte Anforderungsstrom, der über die API einging, konnte nur mit einem Nginx-Protokoll oder einem Anwendungsserver analysiert werden. Dies erlaubte uns nicht, Themenbereiche zu isolieren, außer sie vielleicht nach Benutzern und Abonnenten aufzuteilen. Wenn es nicht möglich ist, die Registrierung der Anwendung oder der Kunden zu regeln, ist es unmöglich, die Situation zu analysieren. Dieses Problem hat sich am wenigsten auf die Entwicklung der API ausgewirkt. Es geht vielmehr darum, ihre Relevanz und Funktionalität zu verstehen.

Versuch Nummer zwei: REST-API

Im Jahr 2010 haben wir versucht, ein Austauschsystem mit Online-Buchhaltung aufzubauen - BukhSoft. Nicht abgehoben. Während des Integrationsprozesses erschien jedoch eine vollwertige API: ein REST-Austauschdienst, bei dem es keine Freiheiten wie Aufrufe von Operationen in Form von RPC-Aufrufen gab. Die gesamte Kommunikation mit der API wurde zum Ausruhen in einen Standardmodus gebracht: Die Abfragezeichenfolge enthält den Namen der Entität, und die damit ausgeführte Operation wird mithilfe der http-Methode festgelegt. Wir haben die Filterung zum Zeitpunkt der Aktualisierung von Entitäten hinzugefügt, und Benutzer haben jetzt die Möglichkeit, die Replikation mit ihren Systemen zu erstellen.

Im selben Jahr erschien eine API zum Entladen von Lager- und Warenbilanzen. Die wertvollsten Teile des Systems wurden den Benutzern über die API zur Verfügung gestellt - der Austausch von Primärdokumenten und geschätzten Daten zu Salden und Kosten von Waren.

Im Dezember 2015 veröffentlichte RetailCRM die erste Drittanbieter-Bibliothek, die auf unsere API zugreift. Sie begannen, es ziemlich aktiv zu nutzen, während die Popularität des gesamten Dienstes zunahm, die Last auf der API schneller wuchs als die Last auf der Weboberfläche. Einmal verwandelte sich das Wachstum in einen Lastsprung.





Und dieser Sprung, der durch den Pfeil links angezeigt wird, führte zu dem völligen Erstaunen des Servers, der unsere API bedient. Eine Woche lang haben wir verstanden, was genau diese Last erzeugt. Es stellte sich heraus, dass dies genau die Anfragen sind, die von den Fronten der Kunden an unsere API gesendet werden. Ungefähr 50 Kunden haben alles gegessen. Damals erkannten wir einen unserer Fehler - das völlige Fehlen von Grenzen.

Infolgedessen haben wir die Anzahl der gleichzeitigen Anforderungen begrenzt. Von einem Konto aus konnten nicht mehr als zwei Anfragen gleichzeitig geöffnet werden. Dies reicht aus, um im Replikationsmodus für den Datenaustausch im Stapelmodus zu arbeiten. Und diejenigen, die uns von diesem Moment an als Backend nutzen wollten, waren gezwungen, die Tarife stärker einzuhalten, da sie die Arbeit an mehreren Konten in ihre Software einführten.

Aufräumen

Seit 2014 ist die Nachfrage nach der vorhandenen API zu einem wichtigen Teil des Geschäfts geworden, und die API selbst hat beim Datenaustausch mit Kunden die größte Datenmenge generiert. 2015 haben wir ein Projekt zur Bereinigung der API gestartet. Wir haben JSON anstelle von XML als Format gewählt und begonnen, es auf der Grundlage der Funktionen zu erstellen, die bei der Implementierung der vorherigen Version enthüllt wurden:

1. Möglichkeit zum Verwalten von Versionen. Mit der Versionierung können Sie eine neue Version entwickeln, ohne eine vorhandene Anwendung zu beeinträchtigen und ohne Benutzer zu stören.
2. Die Fähigkeit des Benutzers, Metadaten in der Antwort zu sehen, die er erhält.
3. Die Möglichkeit, große Dokumente auszutauschen. Wenn wir ein Dokument mit einer Anzahl von mehr als 4-5 Tausend Positionen verarbeiten, wird dies zu einem Problem für den Server: eine lange Transaktion, eine lange http-Anfrage. Wir haben einen speziellen Mechanismus entwickelt, mit dem Sie das Dokument in Teilen aktualisieren und einzelne Positionen dieses Dokuments verwalten können, indem Sie sie an den Server senden.
4. Tools für die Replikation - waren in der vorherigen Version.
5. Die Belastungsgrenzen entsprechen dem Erbe des Schwaders, auf den in der vorherigen Version getreten wurde. Es wurden Beschränkungen für die Anzahl der Anforderungen in einem bestimmten Zeitraum, die Anzahl der gleichzeitigen Anforderungen und Anforderungen von einer IP-Adresse eingeführt.

Von diesem Moment an haben wir zwei kleinere Versionen der API veröffentlicht und mehrere spezialisierte APIs gestartet, aber im Allgemeinen blieb der Ansatz unverändert. Ein aktualisiertes Austauschformat und eine neue Architektur haben es ermöglicht, Mängel in der API viel schneller zu beheben.

MyStore API heute

Heute löst die MyStore-API viele Probleme:

• Datenaustausch mit Online-Shops, Buchhaltungssystemen, Banken;
• Empfangen von Abrechnungsdaten, Berichten;
• Verwendung als Backend für Clientanwendungen - unsere mobilen Anwendungen und Desktop-Kassen arbeiten über die API
• Senden von Benachrichtigungen über Datenänderungen in MyStore - Webhooks;
• Telefonie;
• Loyalitätssysteme.

Basierend auf der API hat unser CEO Askar Rakhimberdiev Nashorn in vier Stunden einen Telegrammbot geschrieben, der den Rest durch die API zieht: github.com/arahimberdiev/com-lognex-telegram-moysklad-stock

Jetzt trockene Zahlen.

Hier sind unsere Statistiken für die alte REST-API:

• 400 Unternehmen;
• 600 Benutzer;
• 2 Millionen Anfragen pro Tag;
• 200 GB / Tag ausgehenden Verkehrs.

Und hier ist, worauf wir mit der gesamten MyStore-API gekommen sind:

• mehr als 70 Integrationen (einige davon finden Sie hier www.moysklad.ru/integratsii );
• 8500 Unternehmen;
• 12.000 Benutzer;
• 46 Millionen Anfragen pro Tag;
• 2 TB / Tag ausgehenden Verkehrs.

Was weiter

API-Entwicklungspläne werden derzeit aktiv diskutiert. Wir versuchen, die Betriebserfahrung zu berücksichtigen, die uns die Benutzer bieten. Nicht immer und nicht alles wird sofort erledigt, aber nicht weit entfernt ist die neue Version der API mit bequemeren Metadaten und einer weniger gewichtigen Struktur, OAuth für die Authentifizierung, eine API für in die Schnittstelle integrierte Anwendungen.

Sie können die Nachrichten auf einer speziellen Website für Integrationsentwickler mit MySklad verfolgen: dev.moysklad.ru .