{"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\/de\/blog\/administrirovanie\/pisali-api-porvali-xml-dva","title":{"rendered":"Wir haben die API geschrieben und XML zerrissen (zweimal)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die erste API von MoegoSk\u0142ada ist vor 10 Jahren erschienen. Seitdem arbeiten wir an den bestehenden API-Versionen und entwickeln neue. Einige Versionen der API wurden bereits eingestellt. <\/p>\n

In diesem Artikel gibt es viel zu entdecken: wie die API entwickelt wurde, warum sie f\u00fcr unseren Cloud-Service wichtig ist, welche Vorteile sie den Nutzern bietet, welche Herausforderungen wir gemeistert haben und was wir als N\u00e4chstes planen.
\n<\/a><\/noindex>
\nMein Name ist Oleg Alexeev oalexeev<\/a><\/noindex>, ich bin technischer Direktor und Mitgr\u00fcnder von MoegoSk\u0142ada. <\/p>\n

Warum eine API f\u00fcr den Service erstellen?<\/h2>\n

\nUnsere Kunden, darunter Zehntausende von Unternehmern, nutzen aktiv Cloud-L\u00f6sungen: Banking, Online-Shops, Warenwirtschaft und CRM. Einmal angeschlossen \u2014 und schon ist es schwer, wieder aufzuh\u00f6ren. Und jetzt bieten der f\u00fcnfte, achte, zehnte Dienst eine Erleichterung f\u00fcr die Unternehmer, aber die Daten zwischen diesen Cloud-Diensten werden manuell \u00fcbertragen. Die Arbeit verwandelt sich in einen Albtraum.<\/p>\n

Eine offensichtliche L\u00f6sung besteht darin, den Nutzern die M\u00f6glichkeit zu geben, Daten zwischen Cloud-Diensten zu \u00fcbertragen. Zum Beispiel k\u00f6nnen Daten als Dateien importiert und exportiert werden, die anschlie\u00dfend in den gew\u00fcnschten Dienst hochgeladen werden. Die Dateien m\u00fcssen normalerweise an das Format jedes Dienstes angepasst werden. Das ist mehr oder weniger einfache Handarbeit, wird aber zunehmend komplizierter, je mehr dieser Dienste hinzukommen.<\/p>\n

Der n\u00e4chste Schritt ist daher die API. Mit ihr profitiert der Cloud-Dienst davon, mehrere Dienste an einem Punkt zu verkn\u00fcpfen. Das Auftreten eines solchen \u00d6kosystems zieht neue Kunden an, da zus\u00e4tzliche Funktionen zur Verf\u00fcgung stehen. Ein Produkt mit neuen Funktionalit\u00e4ten wird dadurch attraktiver und n\u00fctzlicher.<\/p>\n

Wenn eigene Programmierschnittstellen erstellt werden, zieht das Drittanbieter wie Programmierer an, die durch die API auf Ihr Produkt aufmerksam werden. Sie beginnen, L\u00f6sungen auf Basis der angebotenen API zu entwickeln und verdienen Geld mit der Automatisierung der Aufgaben ihrer Kunden.<\/p>\n

Das Buchhaltungssystem von \u041c\u043e\u0435\u0433\u043e\u0421\u043a\u043b\u0430\u0434\u0430 basiert auf einfachen Prozessen. Das Wichtigste ist die Arbeit mit Prim\u00e4rdokumenten, die M\u00f6glichkeit, Waren anzunehmen und auszuliefern, sowie auf Basis der Prim\u00e4rdaten Unternehmensberichte zu erstellen. Zudem gibt es die Daten\u00fcbertragung, beispielsweise an cloudbasierte Buchhaltungssysteme, und die Datenabfrage aus Bankensystemen oder Einzelhandelsstellen. Au\u00dferdem arbeiten wir mit Online-Shops: Wir erhalten Informationen \u00fcber Produkte und senden Daten \u00fcber den Lagerbestand.<\/p>\n

\"Wir
\n<\/p>\n

Die erste API von \u041c\u043e\u0435\u0433\u043e\u0421\u043a\u043b\u0430\u0434\u0430<\/h2>\n

\nNach 10 Jahren Erfahrung mit der API von \u041c\u043e\u0435\u0433\u043e\u0421\u043a\u043b\u0430\u0434\u0430 haben wir zahlreiche Integrationen entwickelt, die einen Datenaustausch erm\u00f6glichen, mit Banken arbeiten, Zahlungen abwickeln und externe Telefonie nutzen.<\/p>\n

Im ersten Jahr haben wir die M\u00f6glichkeit geschaffen, beliebige Daten im XML-Format zu exportieren. Damals war es f\u00fcr die Benutzer viel verst\u00e4ndlicher und gewohnter, Daten offline zu halten, anstatt in einer Cloud, und wir haben ihnen diese Option gegeben. Der Export wurde manuell \u00fcber die Benutzeroberfl\u00e4che gestartet. Man konnte also noch nicht wirklich von einer API sprechen. <\/p>\n

Zu dieser Zeit begannen wir die Zusammenarbeit mit der Firma Rusagro \u2013 sie nutzten bereits ein \u201eerwachsenes\u201c ERP-System zur Produktions- und Vertriebsplanung, w\u00e4hrend die Beladung der Wagen in den Werken in \u041c\u043e\u0435\u043c\u0421\u043a\u043b\u0430\u0434\u0435 automatisiert wurde. So entstanden die ersten Ans\u00e4tze einer echten API: der Austausch zwischen unserem Service und der ERP erfolgte durch den Versand einer gro\u00dfen Datei mit Daten zu allen Dokumenttypen. <\/p>\n

Das ist eine annehmbare Option f\u00fcr den batchweisen Datenaustausch, aber zusammen mit den Dokumenten musste man auch deren Abh\u00e4ngigkeiten \u00fcbermitteln: Informationen zu Produkten, Gesch\u00e4ftspartnern 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 \u00fcber neue Dokumente als auch \u00fcber bereits vorhandene.<\/p>\n

Die erste XML-API hatte eine kurze Lebensdauer \u2013 nach zwei Jahren begannen wir mit ihrer Umgestaltung. Schon zu Beginn ihrer Implementierung machten wir einige Fehler beim Aufbau der Programmierschnittstelle.<\/p>\n

\"Wir
\nWie die XML-API erstellt wurde: eine Illustration von einem unserer Architekten. \u00dcbrigens, erwarten Sie seine Artikel.<\/i><\/p>\n

Hier sind unsere Hauptfehler:<\/p>\n

    \n
  1. Die JAXB-Markierung wurde direkt auf die Entity Beans angewendet. F\u00fcr die Kommunikation mit der Datenbank verwenden wir Hibernate, und auch f\u00fcr 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\u00e4t mit der vorherigen Datenstruktur sicherzustellen.<\/li>\n
  2. Die API entwickelte sich zun\u00e4chst als Erg\u00e4nzung, und wir haben nicht klar definiert, welchen Teil des Produkts sie ausmacht. Wir haben auch nicht dar\u00fcber nachgedacht, ob die API wirklich wichtig ist oder ob wir die Abw\u00e4rtskompatibilit\u00e4t f\u00fcr unsere ersten Kunden aufrechterhalten sollten. F\u00fcr eine Zeit lang machte die Anzahl der API-Nutzer etwa 5 % der insgesamt kleinen Nutzerbasis aus, was dazu f\u00fchrte, dass sie nicht beachtet wurden. Die damals implementierte universelle Filterung f\u00fchrte dazu, dass wir als Backend genutzt wurden. Diese Filterung war zwar nicht ganz GraphQL, aber eine Art davon \u2013 sie funktionierte \u00fcber eine Vielzahl von Abfrageparametern. Mit einem so m\u00e4chtigen 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 \u00dcberraschung heraus, da die Bereitstellung eines solchen Services eine andere Preisgestaltung und ein grunds\u00e4tzliches anderes Verst\u00e4ndnis der API als Produkt erfordern sollte.<\/li>\n
  3. Da sich die API nicht als Hauptprodukt entwickelt hat, wurde die Dokumentation zur API nach dem Prinzip der Restproduktion erstellt und ver\u00f6ffentlicht \u2014 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\u00e4\u00df dieser Arbeitsweise und den Anforderungen um, der Baustein wird getestet, und der Kunde erh\u00e4lt ein Produkt, das den Vorstellungen des Analysten entspricht. Reverse Engineering hingegen bringt ein Produkt auf den Markt, das einfach vorhanden ist: mit provisorischen L\u00f6sungen, seltsamen Entscheidungen und umst\u00e4ndlichen Ans\u00e4tzen anstelle der erforderlichen Funktionalit\u00e4t. <\/li>\n
  4. Der gesamte Anfragefluss, der \u00fcber die API kam, konnte h\u00f6chstens als Nginx- oder Anwendungserver-Protokoll analysiert werden. Das erlaubte es nicht, Themenbereiche herauszustellen, es sei denn, man h\u00e4tte dies nach Benutzern und Abonnenten unterteilt. Wenn es keine M\u00f6glichkeit gibt, die Registrierung der Anwendung oder der Kunden zu steuern, wird es unm\u00f6glich, die Situation zu analysieren. Dieses Problem hatte nur einen minimalen Einfluss auf die Entwicklung der API; es geht vielmehr um das Verst\u00e4ndnis ihrer Nachfrage und Funktionsf\u00fclle.<\/li>\n<\/ol>\n

    <\/p>\n

    Versuch Nummer zwei: REST API<\/h2>\n

    \nIm Jahr 2010 versuchten wir, ein Austauschsystem mit einer Online-Buchhaltungssoftware \u2013 BuchSoft \u2013 aufzubauen. Das hat nicht geklappt. Doch im Zuge der Integration entstand eine vollwertige API: ein REST-Datenaustauschdienst, der keine Freiheiten wie RPC-Anrufe f\u00fcr Operationen enthielt. Die gesamte Kommunikation mit der API wurde auf den standardm\u00e4\u00dfigen REST-Modus reduziert: In der Anfragezeile befindet sich der Name der Entit\u00e4t, und die Operation, die mit ihr durchgef\u00fchrt wird, wird durch die HTTP-Methode definiert. Wir haben die M\u00f6glichkeit zur Filterung nach dem Zeitpunkt der Aktualisierung von Entit\u00e4ten hinzugef\u00fcgt, wodurch Benutzer die M\u00f6glichkeit erhielten, Replikationen mit ihren eigenen Systemen aufzubauen.<\/p>\n

    Im selben Jahr wurde die API f\u00fcr den Export von Lager- und Warenbest\u00e4nden eingef\u00fchrt. \u00dcber die API wurden den Nutzern die wertvollsten Teile des Systems zug\u00e4nglich gemacht \u2013 der Austausch von Prim\u00e4rdokumenten und die Berechnung von Best\u00e4nden sowie den Kosten der Waren.<\/p>\n

    Im Dezember 2015 ver\u00f6ffentlichte RetailCRM die erste externe Bibliothek f\u00fcr den Zugriff auf unsere API. Diese wurde ziemlich aktiv genutzt, w\u00e4hrend die Popularit\u00e4t des Services insgesamt wuchs, und die Last auf der API schneller stieg als die auf der Web-Oberfl\u00e4che. Eines Tages verwandelte sich das Wachstum in einen sprunghaften Anstieg der Last. <\/p>\n

    \"Wir
    \n
    \n\"Wir
    \n
    \nUnd dieser Anstieg, auf den der Zeiger links hinweist, versetzte den Server, der unsere API bedient, in v\u00f6lliges 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\u00fcr verantwortlich. Hier wurde uns einer unserer Fehler klar \u2013 das vollst\u00e4ndige Fehlen von Limits. <\/p>\n

    Wir haben schlie\u00dflich eine Begrenzung f\u00fcr die Anzahl gleichzeitiger Anfragen eingef\u00fchrt. Von einem Konto aus k\u00f6nnen nun nicht mehr als zwei Anfragen gleichzeitig ge\u00f6ffnet werden. Das reicht f\u00fcr den Betrieb im Replikationsmodus aus, um Daten im Batch-Modus auszutauschen. Wer uns als Backend nutzen wollte, musste von diesem Zeitpunkt an st\u00e4rker auf die Tarifbedingungen achten, da die Nutzung mehrerer Konten in ihren Softwaretools eingef\u00fchrt wurde.<\/p>\n

    Organisieren wir es neu<\/h2>\n

    \nBereits seit 2014 ist die Nachfrage nach der verf\u00fcgbaren API ein wichtiger Bestandteil des Gesch\u00e4fts, und die API selbst generierte das gr\u00f6\u00dfte Datenvolumen im Austausch mit Kunden. Im Jahr 2015 haben wir ein Projekt zur Optimierung der API gestartet. Wir w\u00e4hlten 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:<\/p>\n

      \n
    1. M\u00f6glichkeit zur Versionsverwaltung. Die Versionierung erm\u00f6glicht die Entwicklung einer neuen Version, ohne die bestehende Anwendung zu beeintr\u00e4chtigen und den Betrieb der Nutzer zu st\u00f6ren. <\/li>\n
    2. M\u00f6glichkeit, dass der Benutzer Metadaten in der Antwort sieht, die er erh\u00e4lt.<\/li>\n
    3. Die M\u00f6glichkeit, gro\u00dfe Dokumente auszutauschen. Wenn wir ein Dokument mit mehr als 4-5 Tausend Positionen verarbeiten, wird es f\u00fcr den Server problematisch: lange Transaktionen und lange HTTP-Anfragen. Wir haben einen speziellen Mechanismus entwickelt, der es erm\u00f6glicht, das Dokument in Teilen zu aktualisieren und einzelne Positionen zu verwalten, indem wir sie an den Server senden.<\/li>\n
    4. Replikationswerkzeuge \u2013 diese gab es auch in der vorherigen Version.<\/li>\n
    5. Lastgrenzen \u2013 ein Erbe der Probleme, die in der vorherigen Version auftraten. Wir haben Grenzen f\u00fcr die Anzahl der Anfragen innerhalb eines Zeitraums, die Anzahl der parallelen Anfragen und Anfragen von einer IP-Adresse eingef\u00fchrt.<\/li>\n<\/ol>\n

      \nSeitdem haben wir zwei kleinere API-Versionen ver\u00f6ffentlicht und mehrere spezialisierte APIs gestartet, aber der Ansatz blieb insgesamt unver\u00e4ndert. Das aktualisierte Austauschformat und die neue Architektur haben es uns erm\u00f6glicht, M\u00e4ngel im API viel schneller zu beheben.<\/p>\n

      Das API von Mo\u0435\u0433\u043e\u0421\u043a\u043b\u0430\u0434\u0430 heute<\/h2>\n

      \nHeute l\u00f6st das API von Mo\u0435\u0433\u043e\u0421\u043a\u043b\u0430\u0434\u0430 viele Aufgaben:<\/p>\n