{"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":"API geschrieben \u2014 XML (zwei) zerrissen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die erste API von \u041c\u043e\u0435\u0433\u043e\u0421\u043a\u043b\u0430\u0434\u0430 erschien vor 10 Jahren. Seitdem arbeiten wir an den bestehenden API-Versionen und entwickeln neue. Und einige Versionen der API wurden schon eingestellt. <\/p>\n

In diesem Artikel wird es viel geben: wie die API erstellt wurde, warum sie f\u00fcr den Cloud-Service ben\u00f6tigt wird, was sie den Benutzern bietet, auf welche Fallstricke wir gesto\u00dfen sind und was wir als N\u00e4chstes tun m\u00f6chten.
\n<\/a><\/noindex>
\nIch hei\u00dfe Oleg Alexeev oalexeev<\/a><\/noindex>, ich bin technischer Direktor und Mitbegr\u00fcnder von \u041c\u043e\u0435\u0433\u043e\u0421\u043a\u043b\u0430\u0434\u0430. <\/p>\n

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

\nUnsere Kunden, das sind Zehntausende von Unternehmern, nutzen aktiv Cloud-L\u00f6sungen: Banking, Online-Shops, Warenwirtschaft, CRM. Man verbindet sich mit einem \u2014 und schon wird es schwierig, aufzuh\u00f6ren. Und jetzt bieten der f\u00fcnfte, achte, zehnte Service den Unternehmern eine einfachere Arbeit, aber die Daten zwischen diesen Cloud-Services werden manuell \u00fcbertragen. Die Arbeit wird zum Albtraum.<\/p>\n

Eine offensichtliche L\u00f6sung besteht darin, den Benutzern die M\u00f6glichkeit zu geben, Daten zwischen Cloud-Services zu \u00fcbertragen. Zum Beispiel Daten als Dateien zu importieren und zu exportieren, die dann in den gew\u00fcnschten Service hochgeladen werden k\u00f6nnen. Die Dateien werden \u00fcblicherweise an das Format jedes Services angepasst. Das ist mehr oder weniger einfache Handarbeit, aber mit der steigenden Anzahl dieser Services wird es immer schwieriger, das zu erledigen.<\/p>\n

Deshalb ist der n\u00e4chste Schritt die API. Mit ihr gewinnt der Cloud-Service, indem er mehrere Services an einem Punkt verbindet. Das Entstehen eines solchen \u00d6kosystems zieht neue Kunden aufgrund zus\u00e4tzlicher M\u00f6glichkeiten an. Ein Produkt mit neuen Funktionen wird rentabler und n\u00fctzlicher.<\/p>\n

Wenn man eigene Schnittstellen erstellt, zieht das externe Verk\u00e4ufer in Form von Programmierern an, die dank der API von Ihrem Produkt erfahren. Sie beginnen, L\u00f6sungen auf der Grundlage der bereitgestellten API zu erstellen 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\u00e4ren Dokumenten, die M\u00f6glichkeit, Warenannahme und -versand durchzuf\u00fchren, und auf der Grundlage der Prim\u00e4rdaten Berichte f\u00fcr das Gesch\u00e4ft zu erhalten. Au\u00dferdem gibt es die Daten\u00fcbertragung, zum Beispiel an die Cloud-Buchhaltung, und deren Abruf aus Bankensystemen oder Einzelhandelsfl\u00e4chen. Au\u00dferdem arbeiten wir mit Online-Shops: Wir erhalten Informationen \u00fcber Produkte und senden Daten zu Best\u00e4nden.<\/p>\n

\"API
\n<\/p>\n

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

\nIn den 10 Jahren, in denen \u041c\u043e\u0435\u0433\u043e\u0421\u043a\u043b\u0430\u0434\u0430 mit der API arbeitet, haben wir zahlreiche Integrationen entwickelt, die den Datenaustausch erm\u00f6glichen, mit Banken arbeiten, Zahlungen durchf\u00fchren und externe Telefonie nutzen.<\/p>\n

Im ersten Jahr erm\u00f6glichten wir den Export beliebiger Daten im XML-Format. Zu dieser Zeit war es f\u00fcr die Benutzer viel verst\u00e4ndlicher und vertrauter, die Daten offline und nicht in einer Cloud zu speichern, und wir gaben ihnen das. Der Export wurde durch manuelles Exportieren aus der Benutzeroberfl\u00e4che gestartet. Man konnte also noch nicht wirklich von einer API sprechen. <\/p>\n

Damals begannen wir die Zusammenarbeit mit dem Unternehmen \u0420\u0443\u0441\u0430\u0433\u0440\u043e \u2014 sie nutzten bereits ein 'ausgereiftes' ERP zur Produktions- und Vertriebsplanung, w\u00e4hrend die Beladung von Waggons in den Werken im \u041c\u043e\u0451\u043c\u0421\u043a\u043b\u0430\u0434\u0435 automatisiert wurde. So entstanden die ersten Ans\u00e4tze einer echten API: Der Austausch zwischen unserem Dienst und dem ERP erfolgte durch das Versenden gro\u00dfer Dateien mit Daten zu allen Dokumentenarten. <\/p>\n

Das ist eine gute Option f\u00fcr den Batch-Datenaustausch, aber zusammen mit den Dokumenten musste man auch deren Abh\u00e4ngigkeiten \u00fcbermitteln: Informationen \u00fcber Produkte, Gesch\u00e4ftspartner und Lager. Solch ein Datenmix l\u00e4sst sich beim Export nicht so schwer generieren, beim Import jedoch ziemlich schwierig zu entwirren, da alle Informationen in einem Paket ankommen: sowohl \u00fcber neue Dokumente als auch \u00fcber bereits bestehende.<\/p>\n

Die erste XML-API lebte nicht lange \u2014 nach zwei Jahren begannen wir mit ihrer Umstrukturierung. Schon zu Beginn ihrer Arbeit begingen wir einige Fehler beim Aufbau der Programmierschnittstelle.<\/p>\n

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

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

    \n
  1. Die JAXB-Deklaration wurde direkt an Entity Beans vorgenommen. F\u00fcr die Kommunikation mit der Datenbank nutzen wir Hibernate, und f\u00fcr diese Beans wurde ebenfalls die JAXB-Deklaration erstellt. Dieser Fehler trat fast sofort auf: Jede \u00c4nderung der Datenstruktur erforderte eine sofortige Benachrichtigung aller, die die API nutzen, oder den Aufwand, Umgehungsl\u00f6sungen zu finden, die die Kompatibilit\u00e4t mit der vorhergehenden Datenstruktur gew\u00e4hrleisteten.<\/li>\n
  2. API entwickelte sich als eine Art Erg\u00e4nzung, und urspr\u00fcnglich haben wir nicht definiert, welcher Teil des Produkts er ausmacht. Wir haben auch nicht dar\u00fcber nachgedacht, ob die API etwas Wichtiges ist und ob wir r\u00fcckw\u00e4rtskompatibel f\u00fcr die ersten Kunden sein m\u00fcssen. F\u00fcr einen gewissen Zeitraum betrug die Anzahl der API-Nutzer etwa 5 % der insgesamt kleinen Nutzerbasis, und wir haben ihnen keine Beachtung geschenkt. Die damals durchgef\u00fchrte universelle Filterung f\u00fchrte dazu, dass wir als Backend verwendet wurden. Diese Filterung war ganz und gar kein GraphQL, sondern etwas \u00c4hnliches \u2014 sie funktionierte \u00fcber eine Vielzahl von Abfrageparametern. Mit so einem leistungsstarken Werkzeug war es f\u00fcr die Nutzer schwierig, sich zur\u00fcckzuhalten, und die Anfragen wurden so umgeleitet, dass sie direkt von der UI ihrer Online-Shops gesendet wurden. Die Situation wurde zu einer unangenehmen \u00dcberraschung, denn die Bereitstellung eines solchen Dienstes sollte andere Tarifierungen und ein ganz anderes Verst\u00e4ndnis der API als Produkt erfordern.<\/li>\n
  3. Da sich die API nicht als Hauptprodukt entwickelte, wurde die API-Dokumentation nach dem Prinzip des Restes erstellt und ver\u00f6ffentlicht \u2014 durch Reverse Engineering. Dieser Ansatz scheint ziemlich einfach und bequem zu sein, widerspricht jedoch der Vertragsarbeit. Dabei gibt es eine Komponente mit einem festgelegten Funktionsschema. Der Entwickler implementiert sie gem\u00e4\u00df diesem Schema und den Anforderungen, die Komponente wird getestet, und der Kunde erh\u00e4lt ein Produkt, das den Vorstellungen des Analytikers entspricht. Reverse Engineering hingegen wirft ein Produkt auf den Markt, das einfach existiert: mit St\u00fctzen, seltsamen L\u00f6sungen und improvisierten Ans\u00e4tzen anstelle der ben\u00f6tigten Funktionalit\u00e4t. <\/li>\n
  4. Der gesamte Anfragenfluss, der \u00fcber die API kam, konnte nicht mehr als ein Nginx- oder Application Server-Log analysiert werden. Dies erlaubte es nicht, Fachgebiete zu identifizieren, au\u00dfer sie nach Nutzern und Abonnenten zu unterteilen. Wenn keine M\u00f6glichkeit besteht, die Registrierung von Anwendungen oder Kunden zu regulieren, wird die Analyse der Situation unm\u00f6glich. Dieses Problem hatte in geringem Ma\u00dfe Auswirkungen auf die Entwicklung der API, es betrifft mehr das Verst\u00e4ndnis ihres Bedarfs und ihrer Funktionalit\u00e4t.<\/li>\n<\/ol>\n

    <\/p>\n

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

    \nIm Jahr 2010 versuchten wir, ein System f\u00fcr den Austausch mit der Online-Buchhaltungssoftware BuchSoft zu entwickeln. Es kam nicht zustande. Doch im Verlauf der Integration entstand eine vollwertige API: ein REST-Service f\u00fcr den Austausch, bei dem keine Freiheiten wie RPC-Aufrufe vorhanden waren. Alle Kommunikation mit der API wurde auf den f\u00fcr REST typischen Modus umgestellt: In der Anfragezeile befindet sich der Name der Entit\u00e4t, und die durchzuf\u00fchrende Operation wird \u00fcber die HTTP-Methode festgelegt. Wir f\u00fcgten eine Filterung nach dem Aktualisierungszeitpunkt der Entit\u00e4ten hinzu, wodurch die Benutzer die M\u00f6glichkeit hatten, Replikationen mit ihren Systemen zu erstellen.<\/p>\n

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

    Im Dezember 2015 ver\u00f6ffentlichte RetailCRM die erste Drittanbieter-Bibliothek f\u00fcr den Zugriff auf unsere API. Diese wurde ziemlich aktiv genutzt, w\u00e4hrend gleichzeitig die Beliebtheit des Dienstes insgesamt wuchs, und die Last auf der API wuchs schneller als die auf der Weboberfl\u00e4che. Eines Tages verwandelte sich das Wachstum in einen Anstieg der Last. <\/p>\n

    \"API
    \n
    \n\"API
    \n
    \nUnd dieser Anstieg, auf den der Pfeil links hinweist, versetzte den Server, der unsere API bedient, in v\u00f6lliges Erstaunen. Eine Woche lang versuchten wir herauszufinden, was genau diese Last verursachte. Es stellte sich heraus, dass es die Anfragen waren, die von den Frontends der Kunden an unsere API weitergeleitet wurden. Rund 50 Kunden verursachten den gesamten Anstieg. Hier wurde uns einer unserer Fehler bewusst \u2013 die v\u00f6llige Abwesenheit von Limits. <\/p>\n

    Letztendlich f\u00fchrten wir ein Limit f\u00fcr die Anzahl gleichzeitiger Anfragen ein. Mit einem Benutzerkonto konnten nicht mehr als zwei Anfragen gleichzeitig ge\u00f6ffnet werden. Das ist ausreichend f\u00fcr den Betrieb im Replikationsmodus f\u00fcr den Austausch von Daten im Batch-Modus. Diejenigen, die uns als Backend nutzen wollten, mussten sich von diesem Zeitpunkt an st\u00e4rker an die Tarife anpassen, da sie in ihren Programmen Arbeiten mit mehreren Konten implementierten.<\/p>\n

    Wir bringen Ordnung hinein<\/h2>\n

    \nSchon seit 2014 wurde die Nachfrage nach der bestehenden API zu einem wichtigen Teil des Gesch\u00e4fts, und die API generierte das gr\u00f6\u00dfte Datenvolumen im Austausch von Daten mit den Kunden. Im Jahr 2015 starteten wir ein Projekt zur Ordnung der API. Wir w\u00e4hlten als Format JSON anstelle von XML und begannen, sie basierend auf den Besonderheiten zu entwickeln, die wir bei der Implementierung der vorherigen Version festgestellt hatten:<\/p>\n

      \n
    1. Die M\u00f6glichkeit, Versionen zu verwalten. Die Versionierung erm\u00f6glicht die Entwicklung einer neuen Version, ohne die bestehende Anwendung zu beeintr\u00e4chtigen oder den Betrieb der Nutzer zu st\u00f6ren. <\/li>\n
    2. Die M\u00f6glichkeit f\u00fcr den Benutzer, Metadaten in der Antwort zu sehen, 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 dies f\u00fcr den Server zu einem Problem: lange Transaktionen, lange HTTP-Anfragen. Wir haben einen speziellen Mechanismus entwickelt, der es erm\u00f6glicht, das Dokument in Teilen zu aktualisieren und einzelne Positionen dieses Dokuments zu verwalten, indem wir sie an den Server senden.<\/li>\n
    4. Replikationswerkzeuge \u2013 waren auch in der vorherigen Version vorhanden.<\/li>\n
    5. Lastgrenzen \u2013 als Erbe der Stolpersteine, auf die wir in der vorherigen Version gesto\u00dfen sind. Wir haben Limits f\u00fcr die Anzahl der Anfragen in einem bestimmten Zeitraum, die Anzahl paralleler Anfragen und Anfragen von einer IP-Adresse eingef\u00fchrt.<\/li>\n<\/ol>\n

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

      API von \u041c\u043e\u0439\u0421\u043a\u043b\u0430\u0434 heute<\/h2>\n

      \nHeute l\u00f6st die API von \u041c\u043e\u0439\u0421\u043a\u043b\u0430\u0434 viele Aufgaben:<\/p>\n