API i parë i MojeSkledi u shfaq 10 vjet më parë. Gjatë gjithë kësaj kohe, ne kemi punuar mbi versionet ekzistuese të API-së dhe kemi zhvilluar të reja. Disa versione API janë tashmë të harxhuara.
Në këtë artikull do të ketë shumë informacione: si u krijua API, pse është e nevojshme për shërbimin në re, çfarë i ofron përdoruesve, mbi cilat pengesa kemi hasur dhe çfarë dëshirojmë të bëjmë më tej.
Emri im është Oleg Alekseev , unë jam drejtor teknik dhe bashkëthemelues i MojeSkledi.
Pse të krijojmë API për shërbimin
Këta janë klientët tanë, dhe ata janë dhjetëra mijëra sipërmarrës që përdorin aktivisht zgjidhjet në re: bankaria, dyqanet online, menaxhimin e produkteve, CRM. Kur lidhen me një shërbim, është e vështirë të ndalen. Tani veçse shërbimi i pestë, të tetë, të dhjetë e bën punën e sipërmarrësve më të lehtë, por të dhënat midis këtyre shërbimeve në re përdoruesit i transferojnë dorazi. Punët bëhen një makth.
Zgjidhja më e qartë - t’u jepet përdoruesve mundësia për të transferuar të dhënat midis shërbimeve në re. Për shembull, të importojnë dhe eksportojnë të dhëna si skedarë, të cilët më pas mund të ngarkohen në shërbimin e duhur. Skedarët zakonisht i përshtaten formatit të çdo shërbimi. Kjo është një punë manuale më shumë- më pak e thjeshtë, por me rritjen e numrit të këtyre shërbimeve bëhet gjithnjë e më e vështirë ta kryesh atë.
Prandaj, hapi tjetër - API. Me të, shërbimi në re përfiton nga lidhja e disa shërbimeve në një pikë. Shfaqja e një ekosistemi të tillë tërheq klientë të rinj për shkak të mundësive shtesë. Një produkt me funksionalitete të reja bëhet më fitimprurës dhe më i dobishëm.
Nëse krijoni ndërfaqe programore, kjo tërheq shitës të jashtëm në formën e programuesve që dinë për produktin tuaj falë API-së. Ata fillojnë të ndërtsojnë zgjidhje mbi bazën e API-së së propozuar dhe fitojnë para nga automatizimi i detyrave për klientët e tyre.
Sistemi i llogarive të MojeSklad bazohet në procese të thjeshta. E rëndësishme është të punosh me dokumentet fillestare, mundësia për të bërë pranime dhe dërgesa të mallrave, të marrësh raporte për biznesin në bazë të dokumenteve fillestare. Gjithashtu, ka transferim të të dhënave, p.sh. në kontabilitetin në re, dhe marrjen e tyre nga sistemet bankare ose pikave të shitjes. Po ashtu punojmë me dyqanet online: marrim informacion rreth produkteve dhe dërgojmë të dhënat për inventarin.
API i parë i MojeSklad
Pas 10 vjetësh pune të MojeSklad me API, ne kemi grumbulluar një numër të madh integrimesh që lejojnë shkëmbimin e të dhënave, punën me bankat, kryerjen e pagesave dhe përdorimin e telefonisë së jashtme.
Në vitin e parë, ne mundësuam shkarkimin e çdo të dhëne në formatin XML. Atëherë përdoruesve u dukej më e qartë dhe e njohur të mbajnë të dhënat offline, dhe jo në disa re, dhe ne iu ofruam këtë. Shkarkimi fillonte me eksportin manual nga ndërfaqja. Pra, atëherë nuk mund ta quanim ende API.
Po atëherë filluam të bashkëpunojmë me kompaninë Rusagro - ata kishin filluar të përdornin një ERP të avancuar për planifikimin e prodhimit dhe shitjeve, ndërsa ngarkimin e vagonëve në fabrikat e tyre e automatizuan në MojeSklad. Kështu kemi marrë fillimet e një API të vërtetë: shkëmbimi midis shërbimit tonë dhe ERP ndodhte përmes dërgimit të një skedari të madh me të dhëna për të gjitha llojet e dokumenteve.
Kjo ishte një mundësi e mirë për shkëmbimin paketa të të dhënave, por bashkë me dokumentet duhej të transferoheshin edhe varësitë e tyre: informacioni mbi produktet, kontraktuesit dhe magazinat. Të tilla mbetje nuk është aq e vështirë të gjenerosh gjatë eksportit, por mjaft e vështirë për t'u analizuar gjatë importit, pasi në një paketë vijnë të gjitha informacionet: dhe për dokumentet e reja, dhe për ato ekzistues.
API i parë XML nuk jetoi gjatë - pas dy vitesh filluam rindërtimin e tij. Që në fillim të punës së tij, ne bëmë disa gabime në ndërtimin e ndërfaqes programore.
Si u krijua API XML: ilustruar nga një nga arkitektët tanë. Për më tepër, pritni artikujt e tij.
Këtu janë gabimet tona kryesore:
- Markup JAXB was done directly on entity beans. To communicate with the database, we use Hibernate, and JAXB markup was also applied to these beans. This error surfaced almost immediately: any update to the data structure necessitated urgent notification of all those using the API, or the creation of workarounds to ensure compatibility with the previous data structure.
- The API evolved as a sort of add-on, and initially, we didn't define what part of the product it constituted. We also didn't think about whether the API was something important, or if we needed to maintain backward compatibility for its initial clients. At one point, the number of API users was about 5% of the total small number, and they were not paid much attention. The universal filtering that was implemented led to us being used as a backend. This filtering was not quite GraphQL, but something like it — it worked through numerous query string parameters. With such a powerful tool, users found it hard to resist, and requests were routed to us directly from their e-commerce UI. The situation became an unpleasant surprise because providing such a service should require a different pricing model and a completely different understanding of the API as a product.
- Due to the fact that the API developed not as a core product, the API documentation was produced and published on a residual basis — through reverse engineering. This approach may seem quite simple and convenient, but it contradicts contract work. This is when there is a component with a predefined scheme of operation. The developer implements it according to this scheme and task, the component undergoes testing, and the client receives a product that meets the analyst's vision. Reverse engineering, however, throws a product onto the market that simply exists: with workarounds, strange solutions, and makeshift options instead of the required functionality.
- I gjithë fluksi i kërkesave që vinte përmes API-it mund të analizohej sa për log-un e Nginx-it ose të serverit të aplikacionit. Kjo nuk lejonte që të lokalizoheshin fushat tematike, përveç se të ndaheshin sipas përdoruesve dhe abonentëve. Nëse nuk ka mundësi për të rregulluar regjistrimin e aplikacionit ose të klientëve, është e pamundur të analizosh situatën. Ky problem ka ndikuar më pak në zhvillimin e API-it, ai është më shumë për kuptimin e kërkesës së tij dhe mbushjes me funksionalitet.
Përpjekja e dytë: REST API
Në vitin 2010, ne përpiqeshim të ndërtonim një sistem shkëmbimi me kontabilitetin online – Buxhoft. Nuk ia arritëm. Megjithatë, gjatë procesit të integrimit u krijua një API funksional: një shërbim REST për shkëmbim, ku nuk kishte liri si për thirrjet në operacione në formën e thirrjeve RPC. Të gjitha komunikimet me API-in u reduktuan në mënyrën standarde për REST: emri i entitetit është i përfshirë në vargun e kërkesës, dhe operacioni që kryhet me të përcaktohet me metodën http. Ne shtuam filtrimin sipas momentit të azhurnimit të entiteteve, dhe përdoruesit morën mundësinë të ndërtojnë replikimin me sistemet e tyre.
Në të njëjtin vit u shfaq API për shkarkimin e mbetjeve të magazinës dhe produkteve. Pjesët më të çmueshme të sistemit u bënë të aksesueshme për përdoruesit përmes API-it — shkëmbimi i dokumenteve fillestare dhe të dhënat llogaritëse për mbetjet dhe cost-in e produkteve.
Në dhjetor 2015, RetailCRM publikoi bibliotekën e parë të palës së tretë për qasjen në API-in tonë. Ajo filloi të përdorej mjaft aktivisht, ndërkohë që popullariteti i shërbimit rritej në përgjithësi, dhe ngarkesa në API rritej më shpejt se ngarkesa në ndërfaqen e internetit. Një herë rritja u shndërrua në një shpërthim ngarkese.
Dhe ky shpërthim, të cilin e tregon стрелка слева, i la të habitur plotësisht serverin që shërbente API-in tonë. Pasi kaluam një javë duke e shqyrtuar se çfarë pikërisht po gjeneronte këtë ngarkesë. Doli se ishin ato kërkesa, të transmetuara në API-in tonë nga klientët. Rreth 50 klientë e konsumuan të gjithë ngarkesën. Atëherë kuptuam një nga gabimet tona — mungesën e plotë të kufijve.
Si në përfundim ne vendosëm një kufi mbi numrin e kërkesave të njëkohshme. Nga një llogari tani mund të hapen jo më shumë se dy kërkesa në të njëjtën kohë. Kjo është e mjaftueshme për të punuar në mënyrën e replikimit për shkëmbimin e të dhënave në modën e paketave. Ata që donin të na përdorin si backend, nga ky moment duhej të përputhen më shumë me tarifat, pasi filluan të implementojnë një punë me disa llogari në softueret e tyre.
Rregullojmë gjërat
Që nga viti 2014, kërkesa për API-në ekzistuese është bërë një pjesë e rëndësishme e biznesit, dhe vetë API ka gjeneruar volumenin më të madh të të dhënave në shkëmbimin e të dhënave me klientët. Në vitin 2015 nisëm projektin për të rregulluar API-në. Zgjodhëm formatin JSON në vend të XML dhe filluam ta ndërtojmë atë mbi karakteristikat që zbuluam gjatë zbatimit të versionit të mëparshëm:
- Aftësi për të menaxhuar versionet. Versionimi lejon zhvillimin e një versioni të ri pa prekur aplikacionin ekzistues dhe pa e shqetësuar funksionimin e përdoruesve.
- Aftësia për përdoruesin për të parë metadata në përgjigjen që merr.
- Aftësia për shkëmbimin e dokumenteve të mëdha. Nëse ne përpunojmë një dokument me numër pozita më tepër se 4-5 mijë, kjo bëhet një problem për serverin: transaksion i gjatë, kërkesë http e gjatë. Kemi ndërtuar një mekanizëm special që lejon përditësimin e dokumentit në pjesë dhe menaxhimin e pozicioneve të veçanta të këtij dokumenti duke i dërguar ato në server.
- Mjetet për replikimin ishin gjithashtu në versionin e mëparshëm.
- Kufijtë mbi ngarkesën — si trashëgimi e gabimeve në të cilat kemi rënë në versionin e mëparshëm. Vendosëm kufij mbi numrin e kërkesave në një interval kohe, numrin e kërkesave paralele dhe kërkesat nga një ip-adresë.
Që nga ajo kohë kemi lëshuar dy versione të vogla të API-së dhe kemi nisur disa API të specializuara, por si një tërësi, qasja ka mbetur e pandryshuar. Formati i përditësuar i shkëmbimit dhe arkitektura e re kanë lejuar rregullimin e dobësive në API shumë më shpejt.
API e Mojosklad sot
Sot API e Mojosklad zgjidh shumë probleme:
- shkëmbimi i të dhënave me dyqanet online, sistemet e llogarive, bankat;
- marrja e të dhënave të llogarive, raportet;
- përdorimi si backend për aplikacionet klient — aplikacionet tona mobile dhe kasa desktop punojnë nëpërmjet API-së.
- dërgimi i njoftimeve për ndryshimet e të dhënave në Mëngjarëm — webhooks;
- telefonia;
- sistemet e besnikërisë.
Në baza të API, drejtori ynë i përgjithshëm Askar Rakhimberdiev për katër orë shkroi një telegram-bot që merr përmes API mbetjet:
Tani numra të thatë.
Këtu është statistika jonë për API-në e vjetër REST:
- 400 kompani;
- 600 përdorues;
- 2 milion kërkesa në ditë;
- 200 GB/ditë trafiku i dalë.
Dhe ja për çfarë kemi arritur me të gjitha API-të e Mëngjarës:
- më shumë se 70 integrime (disa prej tyre mund të shihen këtu );
- 8500 kompani;
- 12,000 përdorues;
- 46 milion kërkesa në ditë;
- 2 TB/ditë trafiku i dalë.
Çfarë pason
Planet për zhvillimin e API-së janë në diskutim aktiv. Ne përpiqemi të marrim parasysh përvojën e përdorimit, që na ofrojnë përdoruesit. Nuk gjithmonë dhe jo gjithçka arrijmë ta bëjmë menjëherë, por një version i ri i API-së me metadatat më të përshtatshme dhe një strukturë më të thjeshtë, OAuth për autentifikim, API për integrimin në ndërfaqen e aplikacioneve është afër.
Rrjedhni për lajmet në një faqe të veçantë për zhvilluesit e integrimeve me Mëngjarën: .
Burimi: habr.com
