Déi éischt MySklad API erschéngt virun 10 Joer. All dës Zäit hu mir un existente Versioune vun der API geschafft an neier entwéckelt. A verschidde Versioune vun der API si scho begruewe ginn.
Dësen Artikel wäert vill Saache enthalen: wéi d'API erstallt gouf, firwat de Cloud-Service et brauch, wat et de Benotzer gëtt, wéi eng Feeler mir et fäerdeg bruecht hunn ze trëppelen a wat mir als nächst maache wëllen.
Mäin Numm ass Oleg Alekseev , Ech sinn den techneschen Direkter a Matgrënner vu MySklad.
Firwat eng API fir e Service maachen
Eis Clientë, déi Zéngdausende vun Entrepreneuren sinn, benotzen aktiv Cloud-Léisungen: Banking, Online Geschäfter, Commodity Accounting, CRM. Wann Dir mat engem verbënnt, ass et schwéier ze stoppen. An elo de fënneften, aachten, zéngten Service mécht d'Aarbecht vum Entrepreneur méi einfach, awer d'Benotzer transferéieren Daten tëscht dësen Cloud-Servicer manuell. D'Aarbecht gëtt an en Albtraum.
Déi offensichtlech Léisung ass d'Benotzer d'Fäegkeet ze ginn Daten tëscht Cloud Servicer ze transferéieren. Zum Beispill importéieren an exportéieren Daten als Dateien, déi dann op de gewënschten Service eropgeluede kënne ginn. Dateien ginn normalerweis geännert fir de Format vun all Service ze passen. Dëst ass méi oder manner einfach manuell Aarbecht, awer mat der Erhéijung vun der Zuel vun dëse Servicer gëtt et ëmmer méi schwéier ze maachen.
Dofir ass de nächste Schrëtt d'API. Domat profitéiert de Cloud-Service vun der Tatsaach, datt et e puer Servicer op engem Punkt verbënnt. D'Entstoe vun esou engem Ökosystem lackelt nei Clientë wéinst zousätzlech Méiglechkeeten. E Produkt mat neie Funktionalitéit gëtt méi rentabel an nëtzlech.
Wann Dir Är eege Programméierungsschnëttplazen erstellt, lackelt dat Drëtt-Partei Verkeefer an der Form vu Programméierer, déi iwwer Äre Produkt dank der API wëssen. Si fänken un Léisungen ze bauen baséiert op der proposéierter API a verdéngen Sue andeems se hir Clienten hir Aufgaben automatiséieren.
De MySklad Comptablesmethod System baséiert op einfache Prozesser. Den Haapt Saach ass mat primären Dokumenter ze schaffen, d'Fäegkeet fir Wueren ze akzeptéieren an ze verschécken, a Geschäftsberichter op Basis vun primären Dokumenter ze kréien. Et gëtt och d'Iwwerdroung vun Daten, zum Beispill op d'Cloud Accounting, a seng Empfang vu Bankesystemer oder Geschäfter. Mir schaffen och mat Online Geschäfter: Mir kréien Informatiounen iwwer Produkter a schécken Informatiounen iwwer Salden.
Déi éischt API vun MySklad
Während den 10 Joer MySklad mat API schaffen, hu mir all Zorte vun Integratioune kritt, déi eis erlaben Daten auszetauschen, mat Banken ze schaffen, Bezuelungen ze maachen an extern Telefonie ze benotzen.
Am éischte Joer hu mir et méiglech gemaach all Daten am XML-Format erofzelueden. Deemools war et vill méi kloer a méi heefeg fir Benotzer Daten offline ze halen, an net an enger Wollek, a mir hunn et hinnen ginn. Den Eroplueden gouf mam manuellen Export vun der Interface gestart. Dat ass, et konnt nach net eng API genannt ginn.
Zur selwechter Zäit hu mir ugefaang mat der Firma Rusagro ze kooperéieren - si hunn schonn en "erwuessene" ERP fir d'Produktioun a Verkafsplanung benotzt, awer si automatiséiert d'Luede vun Autoen an de Fabriken zu MySklad. Dëst ass wéi mir déi éischt Rudimenter vun enger richteger API kruten: den Austausch tëscht eisem Service an der ERP huet stattfonnt andeems Dir eng grouss Datei mat Daten iwwer all Typ vun Dokumenter geschéckt huet.
Dëst ass eng gutt Optioun fir Batch Datenaustausch, awer zesumme mat Dokumenter hu mir hir Ofhängegkeete missen iwwerdroen: Informatioun iwwer Wueren, Optraghueler a Lagerhaiser. Sou en Dump ass net sou schwéier ze generéieren beim Export, awer et ass zimmlech schwéier ze analyséieren beim Import, well all Informatioun an engem Package kënnt: souwuel iwwer nei Dokumenter wéi iwwer existent.
Déi éischt XML API huet net laang gelieft - zwee Joer méi spéit hu mir ugefaang et nei opzebauen. Och am Ufank vu senger Aarbecht hu mir e puer Feeler gemaach beim Bau vun der Software Interface.
Wéi den XML API gemaach gouf: Illustratioun vun engem vun eisen Architekten. Bleift iwwregens op seng Artikelen.
Hei sinn eis Haaptfehler:
- JAXB Markup gouf direkt op Entitéitsbounen gemaach. Mir benotzen Wanterschlof mat der Datebank ze kommunizéieren, an JAXB Markup gouf fir déi selwecht Bounen gemaach. Dëse Feeler erschéngt bal direkt: all Aktualiséierung vun der Datestruktur huet zu der Bedierfnes gefouert fir dréngend jidderengem ze informéieren deen d'API benotzt, oder Krutchen ze bauen déi d'Kompatibilitéit mat der viregter Datestruktur garantéieren.
- D'API ass als Add-on gewuess, a mir hunn am Ufank net definéiert wéi en Deel vum Produkt et war. Si hunn net emol geduecht ob d'API eppes Wichtegs war, ob et néideg war fir Réckkompatibilitéit fir seng éischt Clienten z'erhalen. Op ee Punkt war d'Zuel vun den API Benotzer ongeféier 5% vun der klenger Zuel, a keng Opmierksamkeet gouf op si bezuelt. Déi universell Filterung, déi zu enger Zäit gemaach gouf, huet dozou gefouert datt mir als Backend benotzt goufen. Dëse Filter war guer net GraphQL, awer eppes wéi dat - et huet duerch vill Ufro String Parameteren geschafft. Mat sou engem mächtege Tool war et schwéier fir d'Benotzer ze widderstoen, an Ufroe goufen un eis transferéiert sou datt se direkt vun der UI vun hiren Online Geschäfter geschéckt goufen. D'Situatioun war eng désagréabel Iwwerraschung, well d'Bereetstellung vun esou engem Service verschidde Präisser an allgemeng aner Verständnis vun der API selwer als Produkt erfuerderen.
- Wéinst der Tatsaach, datt d'API net als Haaptprodukt entwéckelt gouf, gouf d'API-Dokumentatioun produzéiert a publizéiert op enger Reschtbasis - duerch Reverse Engineering. Dëse Wee schéngt ganz einfach a praktesch, awer et widdersprécht ënner engem Kontrakt ze schaffen. Dëst ass wann et e bestëmmte Komponent mat engem virausgesate Betribsschema gëtt. Den Entwéckler implementéiert et am Aklang mat dësem Schema an Aufgab, de Komponent gëtt getest, an de Client kritt e Produkt dat mat der Iddi vum Analyst entsprécht. Reverse Engineering werft e Produit op de Maart, deen einfach existéiert: mat Krutzen, komeschen Léisungen a Vëloen amplaz vun der néideger Funktionalitéit.
- De ganze Stroum vun Ufroen, déi duerch d'API koumen, konnt als näischt méi wéi en Nginx oder Applikatiounsserverlog analyséiert ginn. Dëst huet eis net erlaabt Themeberäicher z'identifizéieren, ausser vläicht vu Benotzer an Abonnenten. Wann et kee Wee ass fir d'Applikatioun oder d'Clientregistréierung ze regléieren, gëtt et onméiglech d'Situatioun ze analyséieren. Dëse Problem hat de mannsten Impakt op d'Entwécklung vun der API; et ass méi iwwer seng Relevanz a Funktionalitéit ze verstoen.
Versuch Nummer zwee: REST API
Am Joer 2010 hu mir probéiert en Austauschsystem mat Online-Comptabilitéit ze bauen - BukhSoft. Huet net ofgeholl. Awer während dem Integratiounsprozess ass e vollwäertege API erschéngt: e REST-Austauschservice, wou et keng Fräiheete waren wéi Zougang zu Operatiounen a Form vun RPC-Uriff. All Kommunikatioun mat der API gouf an de Standardmodus fir Rescht bruecht: d'Ufrolinn enthält den Numm vun der Entitéit, an d'Operatioun déi mat him duerchgefouert gëtt gëtt mat der http Method spezifizéiert. Mir hunn Filter bäigefüügt baséiert op wéini Entitéiten aktualiséiert goufen, an d'Benotzer hunn elo d'Méiglechkeet fir Replikatioun mat hire Systemer ze bauen.
Am selwechte Joer ass eng API fir d'Entluedung vum Lager- an Inventarsaldo opgetaucht. Déi wäertvollst Deeler vum System sinn fir Benotzer via API verfügbar ginn - den Austausch vun primären Dokumenter a berechent Daten iwwer Salden an d'Käschte vu Wueren.
Am Dezember 2015, RetailCRM publizéiert déi éischt Drëtt Partei Bibliothéik fir Zougang zu eiser API. Et huet ugefaang zimlech aktiv ze benotzen, während d'Popularitéit vum Service als Ganzt gewuess ass, ass d'Laascht op der API méi séier gewuess wéi d'Laascht op der Webinterface. Enges Daags Wuesstem zu Laascht Iwwerschwemmung verwandelt.
An dëse Sprong, gezeechent vum Pfeil op der lénker Säit, huet de Server komplett iwwerrascht, deen eis API servéiert. Mir hunn eng Woch verbruecht fir erauszefannen wat genee dës Belaaschtung generéiert. Et huet sech erausgestallt datt dëst déiselwecht Ufroe sinn, déi un eis API vun de Clientfronten iwwerdroe ginn. Eng 50 Clientë hunn alles giess. Et war deemools datt mir ee vun eise Feeler realiséiert hunn - e komplette Mangel u Grenzen.
Als Resultat hu mir eng Limit op d'Zuel vun de simultan Ufroen agefouert. Et ass elo méiglech net méi wéi zwou Ufroe gläichzäiteg vun engem Kont opzemaachen. Dëst ass genuch fir am Replikatiounsmodus fir Datenaustausch am Batchmodus ze schaffen. An déi, déi eis als Backend wollten notzen, goufen vun deem Moment un gezwongen, den Tariffer besser ze respektéieren, well se Aarbecht op verschiddene Konten an hir Software agefouert hunn.
Loosst eis et an Uerdnung setzen
Schonn zënter 2014 ass d'Demande fir déi existent API e wichtege Bestanddeel vum Geschäft ginn, an d'API selwer generéiert de gréisste Volumen vun Daten am Austausch vun Daten mat Clienten. Am 2015 hu mir e Projet gestart fir d'API ze botzen. Mir hunn JSON amplaz XML als Format gewielt an hunn ugefaang et ze bauen op Basis vun de Funktiounen, déi während der Ëmsetzung vun der viregter Versioun identifizéiert goufen:
- Fäegkeet Versiounen ze managen. Versioning erlaabt Iech eng nei Versioun z'entwéckelen ouni déi existent Applikatioun ze beaflossen oder d'Benotzererfarung ze stéieren.
- D'Fäegkeet fir de Benotzer Metadaten an der Äntwert selwer ze gesinn déi hien kritt.
- Fäegkeet fir grouss Dokumenter auszetauschen. Wa mir en Dokument mat méi wéi 4-5 dausend Positiounen veraarbecht, gëtt dëst e Problem fir de Server: eng laang Transaktioun, eng laang http Ufro. Mir hunn e spezielle Mechanismus gebaut, deen Iech erlaabt Iech en Dokument an Deeler ze aktualiséieren an individuell Positiounen vun dësem Dokument ze verwalten andeems Dir se op de Server schéckt.
- Tools fir Replikatioun waren och an der viregter Versioun präsent.
- D'Laaschtlimite si wéi e Patrimoine vun der Rake, déi an der viregter Versioun getratt gouf. Mir hunn Limiten op d'Zuel vun den Ufroen an enger Zäit agefouert, d'Zuel vu parallelen Ufroen an Ufroe vun enger IP Adress.
Zënterhier hu mir zwou kleng Versioune vun der API verëffentlecht an e puer spezialiséiert APIen lancéiert, awer d'Gesamt Approche ass onverännert bliwwen. Den aktualiséierten Austauschformat an déi nei Architektur hunn et méiglech gemaach Mängel an der API vill méi séier ze korrigéieren.
MySklad API haut
Haut léist d'MySklad API vill Probleemer:
- Datenaustausch mat Online Geschäfter, Comptabilitéitssystemer, Banken;
- Erhalen berechent Donnéeën a Rapporten;
- benotzt als Backend fir Client Uwendungen - eis mobil Uwendungen an Desktop Cash Register funktionnéieren iwwer API
- Schécken vun Notifikatiounen iwwer Daten Ännerungen am MySklad - webhooks;
- Telefonie;
- Loyalitéit Systemer.
Baséierend op der API, eise CEO Askar Rakhimberdiev a véier Stonnen hunn ech en Telegram Bot geschriwwen deen Iwwerreschter duerch d'API zitt:
Elo dréchen Zuelen.
Hei sinn eis Statistike fir déi al REST API:
- 400 Firmen;
- 600 Benotzer;
- 2 Milliounen Demanden pro Dag;
- 200 GB / Dag vun erausginn Verkéier.
An hei ass wat mir fir all MySklad APIen erauskomm sinn:
- méi wéi 70 Integratiounen (e puer vun hinnen kënnen hei gekuckt ginn );
- 8500 Firmen;
- 12 Benotzer;
- 46 Milliounen Demanden pro Dag;
- 2 TB / Dag vun erausginn Verkéier.
Wat ass Next
API Entwécklung Pläng sinn ënner aktiv Diskussioun. Mir probéieren d'Operatiounserfarung ze berücksichtegen, déi d'Benotzer eis ubidden. Et ass net ëmmer méiglech alles gläichzäiteg ze maachen, awer eng nei Versioun vun der API ass just ronderëm den Eck mat méi praktesch Metadaten an enger manner flauscher Struktur, OAuth fir Authentifikatioun, an eng API fir Uwendungen, déi an der Interface agebaut sinn.
Dir kënnt d'Noriichten op enger spezieller Websäit fir Entwéckler vun Integratioune mat MySklad verfollegen: .
Source: will.com