API i parĂ« i MoŃgoskad ka dalĂ« 10 vjet mĂ« parĂ«. GjatĂ« gjithĂ« kĂ«tyre viteve ne kemi punuar nĂ« versionet ekzistuese tĂ« API-sĂ« dhe kemi zhvilluar tĂ« reja. Disa versione tĂ« API-sĂ« tashmĂ« kanĂ« pĂ«rfunduar nĂ« humbje.
Në këtë artikull do të ketë shumë gjëra: si u krijua API, përse është i nevojshëm për shërbimin në cloud, çfarë u ofron përdoruesve, në cilat gremina kemi rënë dhe çfarë dëshirojmë të bëjmë më tej.
MĂ« quajnĂ« Oleg Alekseev , jam drejtori teknik dhe bashkĂ«themeluesi i MoŃgoskad.
Përse të krijojmë API për shërbimin
KĂ«ta janĂ« klientĂ«t tanĂ«, qĂ« pĂ«rfshijnĂ« dhjetĂ«ra mijĂ«ra sipĂ«rmarrĂ«s, qĂ« e pĂ«rdorin aktivisht zgjidhjet nĂ« cloud: bankarizimin, dyqanet online, menaxhimin e mallrave, CRM. TĂ« lidheni me njĂ« shĂ«rbim â dhe Ă«shtĂ« e vĂ«shtirĂ« tĂ« ndaloni. Dhe ja ku shĂ«rbimi i pestĂ«, tĂ« tetin, tĂ« dhjetin i bĂ«n punĂ«n e sipĂ«rmarrĂ«sve mĂ« tĂ« lehtĂ«, por tĂ« dhĂ«nat ndĂ«rmjet kĂ«tyre shĂ«rbimeve nĂ« cloud pĂ«rdoruesit i transferojnĂ« nĂ« mĂ«nyrĂ« manuale. Puna kthehet nĂ« njĂ« makth.
Një zgjidhje evidente është t'u jepet përdoruesve mundësia për të transferuar të dhëna midis shërbimeve cloud. Për shembull, të importojnë dhe eksportojnë të dhëna si skedarë, të cilat mund të ngarkohen më pas në shërbimin e dëshiruar. Skedarët zakonisht përshtaten për formatin e secilit shërbim. Kjo është një punë manuale më shumë-shumë e thjeshtë, por me rritjen e numrit të këtyre shërbimeve, realizimi i saj bëhet gjithnjë e më i komplikuar.
Prandaj, hapi tjetër është API. Me të, shërbimi cloud përfiton duke lidhur disa shërbime në një pikë. Shfaqja e një ekosistemi të tillë tërheq klientë të rinj përmes mundësive shtesë. Një produkt me funksionalitete të reja bëhet më i leverdishëm dhe më i dobishëm.
NĂ«se krijoni ndĂ«rfaqe programesh tĂ« veta, kjo tĂ«rheq shitĂ«s tĂ« tretĂ« nĂ« formĂ«n e programistĂ«ve qĂ« dinĂ« pĂ«r produktin tuaj falĂ« API. Ata fillojnĂ« tĂ« ndĂ«rt ÎșÎŹÎœÎżÏ Îœ zgjidhje mbi bazĂ«n e API tĂ« propozuar dhe fitojnĂ« para nga automatizimi i detyrave tĂ« klientĂ«ve tĂ« tyre.
Sistemi i menaxhimit tĂ« MoiSkĆad ndihmon nĂ« proceset e thjeshta. E rĂ«ndĂ«sishmja Ă«shtĂ« puna me dokumentet e para, mundĂ«sia pĂ«r tĂ« kryer pranim dhe dĂ«rgim tĂ« mallrave, si dhe pĂ«r tĂ« marrĂ« raporte pĂ«r biznesin bazuar nĂ« kĂ«to dokumente. NjĂ«kohĂ«sisht, ka transferime tĂ« tĂ« dhĂ«nave, pĂ«r shembull nĂ« kontabilitetin nĂ« re, si dhe marrjen e tyre nga sistemet bankare ose pika tĂ«shitjes. Gjithashtu, ne punojmĂ« me dyqanet online: theksojmĂ« informacionin mbi produktet dhe dĂ«rgojmĂ« tĂ« dhĂ«na pĂ«r stoqet.
API i ParĂ« i MoiSkĆad
GjatĂ« 10 viteve tĂ« punĂ«s sĂ« MoiSkĆad me API, ne kemi krijuar integrime tĂ« çdo lloji, 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 krijuam mundësinë për të eksportuar çdo të dhënë në formatin XML. Atëherë përdoruesit kishin një kuptim më të qartë dhe më të zakonshëm të mbajtjes së të dhënave në offline, sesa në ndonjë shërbim online, dhe ne u ofruam këtë mundësi. Eksporti iniciohej me anë të një eksportimi manual nga ndërfaqja. Pra, API nuk mund të quhej ende i tillë.
Kjo Ă«shtĂ« kohĂ« kur filluam tĂ« bashkĂ«punojmĂ« me kompaninĂ« Rusagro â ata tashmĂ« kishin pĂ«rdorur njĂ« ERP 'tĂ« rritur' pĂ«r planifikimin e prodhimit dhe shpĂ«rndarjes, ndĂ«rsa automatizimin e ngarkesave nĂ« fabrikat e tyre e realizuan me MĂłjSklad. KĂ«shtu, gjeneruam hapat e parĂ« drejt njĂ« API tĂ« vĂ«rtetĂ«: shkĂ«mbimi midis shĂ«rbimit tonĂ« dhe ERP-sĂ« bĂ«hej pĂ«rmes dĂ«rgimit tĂ« njĂ« skedari tĂ« madh me tĂ« dhĂ«na pĂ«r tĂ« gjithĂ« llojet e dokumenteve.
Ky është një opsion i mirë për shkëmbim grupor të të dhënave, por së bashku me dokumentet duhej të dërgoheshin edhe varësitë e tyre: informacionet për produktet, kontraktuesit dhe magazinat. Një përzierje e tillë është e lehtë për t'u gjeneruar gjatë eksportit, por shumë e vështirë për tu ndarë gjatë importit, pasi në një paketë vijnë të gjitha informacionet: si për dokumentet e reja, ashtu edhe për ato ekzistuese.
XML API-i i parĂ« nuk jetoi shumĂ« â pas dy vitesh filluam riparimin e tij. QĂ« nĂ« fillim tĂ« funksionimit, bĂ«mĂ« disa gabime nĂ« ndĂ«rtimin e ndĂ«rfaqes sĂ« programit.
Si u ndërtua XML API: ilustruar nga një nga arkitektët tanë. Përshtypje, prisni artikujt e tij.
Këto janë gabimet tona kryesore:
- Markup JAXB është bërë direkt mbi entity beans. Për të komunikuar me bazën e të dhënave, ne përdorim Hibernate, dhe markup JAXB është bërë për këto bina. Ky gabim u shfaq pothuajse menjëherë: çdo azhurnim i strukturës së të dhënave përfundonte me nevojën për të njoftuar me urgjencë gjithë ata që përdorin API-in, ose ndërtimin e kostileve që do të siguronin përputhshmërinë me strukturën e mëparshme të të dhënave.
- API filloi si njĂ« shtesĂ«, dhe fillimisht ne nuk e caktuam se cila pjesĂ« e produktit pĂ«rbĂ«nte. As nuk menduam nĂ«se API-i ishte diçka e rĂ«ndĂ«sishme, nĂ«se duhet tĂ« mbaheshin standardet e prapambetjes pĂ«r klientĂ«t e tij tĂ« parĂ«. NĂ« njĂ« moment, numri i pĂ«rdoruesve tĂ« API-sĂ« pĂ«rbĂ«nte rreth 5% tĂ« numrit tĂ« vogĂ«l total, dhe nuk u kushtua vĂ«mendje. Filtrimi universalisht i bĂ«rĂ« nĂ« atĂ« kohĂ« çoi nĂ« pĂ«rdorimin tonĂ« si backend. Ky filtrim nuk ishte saktĂ«sisht GraphQL, por diçka e ngjashme â funksiononte pĂ«rmes njĂ« numri tĂ« madh parametrash nĂ« kĂ«rkesĂ«n e url-sĂ«. Me njĂ« mjet kaq tĂ« fuqishĂ«m, pĂ«rdoruesit u ndjenĂ« tĂ« detyruar tĂ« kalonin tek ne, dhe kĂ«rkesat u dĂ«rguan direkt nga UI i dyqaneve tĂ« tyre online. Situata u bĂ« njĂ« befasi e pakĂ«ndshme, sepse ofrimi i njĂ« shĂ«rbimi tĂ« tillĂ« duhet tĂ« kĂ«rkonte njĂ« tarifim tĂ« ndryshĂ«m dhe, nĂ« fakt, njĂ« kuptim tĂ« ndryshĂ«m tĂ« vetĂ« API si produkt.
- PĂ«r shkak se API Ă«shtĂ« zhvilluar mĂ« shumĂ« si njĂ« produkt anĂ«sor, dokumentacioni pĂ«r API Ă«shtĂ« bĂ«rĂ« dhe publikuar nĂ« mĂ«nyrĂ« tĂ« nĂ«nkuptuar â pĂ«rmes inxhinierisĂ« sĂ« kundĂ«rt. Ky proces duket mjaft i thjeshtĂ« dhe i pĂ«rshtatshĂ«m, por Ă«shtĂ« nĂ« kundĂ«rshtim me punĂ«n sipas kontratĂ«s. Kjo ndodh kur ka njĂ« komponent me njĂ« skemĂ« pune tĂ« instaluar paraprakisht. Zhvilluesi e realizon atĂ« nĂ« pĂ«rputhje me kĂ«tĂ« skemĂ« dhe detyrĂ«, komponenti kalon testimin, klienti merr njĂ« produkt qĂ« pĂ«rputhet me vizionin e analistit. Inxhinieria e kundĂ«rt, nga ana tjetĂ«r, lanzon nĂ« treg njĂ« produkt qĂ« thjesht ekziston: me zgjidhje improvizuese, zgjidhje tĂ« çuditshme dhe âbicikletaâ nĂ« vend tĂ« funksionalitetit tĂ« nevojshĂ«m.
- I gjithë fluksi i kërkesave që vinte përmes API-t mund të analizohej vetëm si një log i Nginx-it ose i serverit të aplikacioneve. Kjo nuk lejonte identifikimin e fushave 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, analizimi i situatës bëhet i pamundur. Ky problem ndikon pak në zhvillimin e API-t, pasi lidhet më shumë me kuptimin e kërkesës për të dhe përmbushjen e funksionalitetit.
Përpjekja e dytë: REST API
NĂ« vitin 2010, ne pĂ«rpiqeshim tĂ« ndĂ«rtonim njĂ« sistem shkĂ«mbimi me kontabilitetin online â BuxhoSoft. Nuk funksionoi. MegjithatĂ«, gjatĂ« procesit tĂ« integrimit u krijua njĂ« API i plotĂ«: njĂ« shĂ«rbim REST pĂ«r shkĂ«mbim, ku mungonin lirimet si thirrjet e operacioneve si thirrje RPC. TĂ« gjitha komunikimet me API-nĂ« u orientuan nĂ« mĂ«nyrĂ«n standarde pĂ«r REST: nĂ« vargun e kĂ«rkesĂ«s pĂ«rmban emrin e entitetit, ndĂ«rsa operacioni qĂ« kryhet me tĂ« pĂ«rcaktohet me metodĂ«n http. Ne shtuam filtrimin sipas momentit tĂ« pĂ«rditĂ«simit tĂ« entiteteve, dhe pĂ«rdoruesit morĂ«n mundĂ«sinĂ« tĂ« ndĂ«rtuan replikimin me sistemet e tyre.
NĂ« tĂ« njĂ«jtin vit, u shfaq API pĂ«r transferimin e inventarit dhe stokut tĂ« produkteve. PĂ«r pĂ«rdoruesit u bĂ«nĂ« tĂ« aksesueshme pĂ«rmes API-sĂ« pjesĂ«t mĂ« tĂ« çmuara tĂ« sistemit â shkĂ«mbimi i dokumenteve fillestare dhe tĂ« dhĂ«nat llogaritĂ«se pĂ«r stoqet dhe koston e produkteve.
Në dhjetor 2015, RetailCRM publikoi bibliotekën e parë të jashtme për akses në API-në tonë. Ajo filloi të përdorej mjaft aktiivisht, ndërkohë që po rritej popullariteti i shërbimit në tërësi, ngarkesa në API po rritej më shpejt sesa ngarkesa në ndërfaqen e webit. Një herë, rritja u shndërrua në një skok ngarkese.
Dhe ky skok, pĂ«r tĂ« cilin tregon shigjeta e majtĂ«, çoi nĂ« njĂ« habi tĂ« plotĂ« tĂ« serverit qĂ« shĂ«rbente API-nĂ« tonĂ«. NjĂ« javĂ« ne u merrem me atĂ« çfarĂ« e gjeneronte kĂ«tĂ« ngarkesĂ«. Doli se ishin ato kĂ«rkesa qĂ« transmetoheshin nĂ« API-nĂ« tonĂ« nga frontet e klientĂ«ve. Rreth 50 klientĂ« ishin pĂ«rgjegjĂ«s pĂ«r gjithçka. AtĂ«herĂ« kuptuam njĂ« nga gabimet tona â mungesĂ«n e plotĂ« tĂ« limiteve.
Në fund, vendosëm një kufi për numrin e kërkesave në të njëjtën kohë. Me një llogari ishte e mundur të hapnim jo më shumë se dy kërkesa në të njëjtën kohë. Kjo është e mjaftueshme për të punuar në mënyrë replikimi për shkëmbimin e të dhënave në modulin e paketave. Ndërsa ata që donin të përdorin shërbimin tonë si backend, nga ky moment ishin të detyruar të përputhen më mirë me tarifat, pasi vendosëm që programet e tyre të punonin me disa llogari.
Rregullojmë
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 volumet më të mëdha të të dhënave gjatë shkëmbimit me klientët. Në vitin 2015, ne nisëm një projekt për rregullimin e API-së. Zgjodhëm formatin JSON në vend të XML dhe filluam ta ndërtuam atë mbi karakteristikat që identifikuam gjatë implementimit të versionit të kaluar:
- Aftësia për të menaxhuar versionet. Versionimi lejon zhvillimin e një versioni të ri, pa prekur aplikacionin ekzistues dhe pa ndërprerë funksionimin e përdoruesve.
- Aftësia për përdoruesin që të shohë metadatat në përgjigjen që merr.
- Mundësia për të shkëmbyer dokumente të mëdha. Nëse ne përpunojmë një dokument me më shumë se 4-5 mijë pozita, kjo bëhet një problem për serverin: një transaksion i gjatë, një kërkesë http e gjatë. Ndërtuam një mekanizëm të veçantë që lejon përditësimin e dokumentit në pjesë dhe menaxhimin e pozita të veçanta të këtij dokumenti, duke i dërguar ato në server.
- Mjetet pĂ«r replikim â kanĂ« qenĂ« edhe nĂ« versionin e mĂ«parshĂ«m.
- Limite tĂ« ngarkesĂ«s â si trashĂ«gimi e njĂ« problematike nga versioni i mĂ«parshĂ«m. Njoftuam limite pĂ«r numrin e kĂ«rkesave nĂ« njĂ« interval kohe, numrin e kĂ«rkesave paralele dhe kĂ«rkesat nga njĂ« adresĂ« IP.
Që nga ajo kohë, ne kemi lëshuar dy versione të vogla të API-së dhe kemi lançuar disa API të specializuara, por në përgjithësi, qasja ka mbetur e pandryshuar. Formati i përditësuar i shkëmbimit dhe arkitektura e re lejuan korrigjimin e dobësive në API shumë më shpejt.
API-së së MojeSklad sot
Sot API-ja e MojeSklad zgjidh shumë detyra:
- shkëmbimi i të dhënave me dyqanet online, sistemet e llogarive, bankat;
- marrja e të dhënave për llogaritje, raporte;
- pĂ«rdorimi si backend pĂ«r aplikacionet kliente â aplikacionet tona celulare dhe kasat desktop punojnĂ« pĂ«rmes API-sĂ«
- dĂ«rgimi i njoftimeve pĂ«r ndryshimet e tĂ« dhĂ«nave nĂ« MĂłjSklad â webhooks;
- telefonia;
- sistemet e lojalitetit.
Në bazë të API-së, drejtori ynë i përgjithshëm Askar Rahimberdiev në katër orë shkroi një bot të Telegramit, i cili merr përmes API-së stoqet:
Tani numrat e thata.
Ja statistika jonë për API-në e vjetër REST:
- 400 kompani;
- 600 përdorues;
- 2 milion kërkesa në ditë;
- 200 GB/ditë trafik dalës.
Këtu është se çfarë arritëm për të gjithë API-të e MójSklad:
- më shumë se 70 integërime (disa prej tyre mund të shihen këtu );
- 8500 kompani;
- 12 000 përdorues;
- 46 milion kërkesa në ditë;
- 2 TB/ditë trafik dalës.
ĂfarĂ« ndodh mĂ« pas
Planet për zhvillimin e API-së janë në diskutim aktiv. Ne përpiqemi të marrim parasysh përvojën e përdorimit, të cilën na e ofrojnë përdoruesit. Nuk është gjithmonë e mundur të bëjmë gjithçka menjëherë, por një version i ri i API-së me metad data më të përshtatshme dhe një strukturë më të thjeshtë, OAuth për autentifikim, API për integrimin në ndërfaqet e aplikacioneve është afër.
Mund të ndiqni lajmet në një faqe të veçantë për zhvilluesit e integrimeve me MoimSklad: .
Burimi: habr.com
