La unua MySklad API aperis antaŭ 10 jaroj. Dum ĉi tiu tempo ni laboris pri ekzistantaj versioj de la API kaj disvolvis novajn. Kaj pluraj versioj de la API jam estis entombigitaj.
Ĉi tiu artikolo enhavos multajn aferojn: kiel la API estis kreita, kial la nuba servo bezonas ĝin, kion ĝi donas al uzantoj, kiajn erarojn ni sukcesis paŝi kaj kion ni volas fari poste.
Mia nomo estas Oleg Alekseev , mi estas la teknika direktoro kaj kunfondinto de MySklad.
Kial fari API por servo
Niaj klientoj, kiuj estas dekoj da miloj da entreprenistoj, aktive uzas nubajn solvojn: bankado, interretaj vendejoj, varo kontado, CRM. Post kiam vi konektiĝas al unu, estas malfacile ĉesi. Kaj nun la kvina, oka, deka servo faciligas la laboron de la entreprenisto, sed uzantoj permane transdonas datumojn inter ĉi tiuj nubaj servoj. Laboro fariĝas koŝmaro.
La evidenta solvo estas doni al uzantoj la kapablon transdoni datumojn inter nubaj servoj. Ekzemple, importu kaj eksportu datumojn kiel dosierojn, kiuj tiam povas esti alŝutitaj al la dezirata servo. Dosieroj estas kutime ŝanĝitaj por konveni la formaton de ĉiu servo. Ĉi tio estas pli-malpli simpla mana laboro, sed kun la kresko de la nombro de ĉi tiuj servoj, ĝi fariĝas pli kaj pli malfacila por plenumi.
Tial, la sekva paŝo estas la API. Per ĝi, la nuba servo profitas de la fakto, ke ĝi konektas plurajn servojn en unu momento. La apero de tia ekosistemo altiras novajn klientojn pro pliaj ŝancoj. Produkto kun nova funkcieco fariĝas pli profita kaj utila.
Se vi kreas viajn proprajn programajn interfacojn, ĉi tio altiras triajn vendistojn en formo de programistoj, kiuj scias pri via produkto danke al la API. Ili komencas konstrui solvojn bazitajn sur la proponita API kaj gajni monon aŭtomatigante la taskojn de siaj klientoj.
La kontada sistemo MySklad baziĝas sur simplaj procezoj. La ĉefa afero estas labori kun ĉefaj dokumentoj, la kapablo akcepti kaj sendi varojn, kaj ricevi komercajn raportojn bazitajn sur ĉefaj dokumentoj. Ekzistas ankaŭ la translokigo de datumoj, ekzemple al nuba kontado, kaj ĝia kvitanco de bankaj sistemoj aŭ podetalaj butikoj. Ni ankaŭ laboras kun interretaj vendejoj: ni ricevas informojn pri produktoj kaj sendas informojn pri saldo.
La unua API de MySklad
Dum la 10 jaroj de MySklad laboranta kun API, ni akiris ĉiajn integraĵojn, kiuj ebligas al ni interŝanĝi datumojn, labori kun bankoj, pagi kaj uzi eksteran telefonion.
En la unua jaro, ni ebligis elŝuti ajnajn datumojn en XML-formato. Tiam, estis multe pli klare kaj pli ofta por uzantoj konservi datumojn eksterrete, kaj ne en iu nubo, kaj ni donis ĝin al ili. La alŝuto estis komencita per mana eksportado de la interfaco. Tio estas, ĝi ankoraŭ ne povus esti nomita API.
Samtempe ni komencis kunlabori kun la kompanio Rusagro - ili jam uzis "plenkreskan" ERP por produktado kaj venda planado, sed ili aŭtomatigis la ŝarĝon de aŭtoj en fabrikoj en MySklad. Jen kiel ni akiris la unuajn rudimentojn de vera API: la interŝanĝo inter nia servo kaj ERP okazis sendante grandan dosieron kun datumoj pri ĉiaj dokumentoj.
Ĉi tio estas bona eblo por interŝanĝo de bataj datumoj, sed kune kun dokumentoj ni devis transdoni iliajn dependecojn: informojn pri varoj, entreprenistoj kaj magazenoj. Tia rubujo ne estas tiel malfacile generi dum eksportado, sed estas sufiĉe malfacile analizebla dum importado, ĉar ĉiuj informoj venas en unu pako: kaj pri novaj dokumentoj kaj pri ekzistantaj.
La unua XML API ne longe vivis - du jarojn poste ni komencis rekonstrui ĝin. Eĉ ĉe la komenco de ĝia laboro, ni faris plurajn erarojn dum konstruado de la programara interfaco.
Kiel la XML API estis farita: ilustraĵo de unu el niaj arkitektoj. Cetere, restu atenta pri liaj artikoloj.
Jen niaj ĉefaj eraroj:
- JAXB markado estis farita rekte sur entaj faboj. Ni uzas Hibernate por komuniki kun la datumbazo, kaj JAXB markado estis farita por la samaj faboj. Ĉi tiu eraro aperis preskaŭ tuj: ĉiu ĝisdatigo de la datumstrukturo kondukis al la bezono urĝe sciigi ĉiujn, kiuj uzas la API, aŭ konstrui lambastonojn, kiuj certigus kongruecon kun la antaŭa datumstrukturo.
- La API kreskis kiel aldonaĵo, kaj ni komence ne difinis, kia parto de la produkto ĝi estas. Ili eĉ ne pensis, ĉu la API estas io grava, ĉu necesas konservi malantaŭan kongruon por siaj unuaj klientoj. En unu momento, la nombro da API-uzantoj estis ĉirkaŭ 5% de la malgranda nombro, kaj neniu atento estis atentita al ili. La universala filtrado farita iam kondukis al ni uzata kiel backend. Ĉi tiu filtrado tute ne estis GraphQL, sed io tia - ĝi funkciis per multaj demandaj ĉenaj parametroj. Kun tia potenca ilo, estis malfacile por uzantoj rezisti, kaj petoj estis transdonitaj al ni tiel ke ili estis senditaj rekte de la UI de siaj interretaj vendejoj. La situacio estis malagrabla surprizo, ĉar la liverado de tia servo devus postuli malsaman prezon kaj ĝenerale malsaman komprenon de la API mem kiel produkto.
- Pro la fakto, ke la API ne estis evoluigita kiel ĉefa produkto, API-dokumentado estis produktita kaj publikigita sur resta bazo - per inversa inĝenierado. Ĉi tiu vojo ŝajnas sufiĉe simpla kaj oportuna, sed ĝi kontraŭdiras labori sub kontrakto. Ĉi tio estas kiam ekzistas certa komponanto kun antaŭfiksita operacia skemo. La programisto efektivigas ĝin laŭ ĉi tiu skemo kaj tasko, la komponanto estas provita, la kliento ricevas produkton, kiu kongruas kun la ideo de la analizisto. Inversa inĝenierado ĵetas sur la merkaton produkton kiu simple ekzistas: kun lambastonoj, strangaj solvoj kaj bicikloj anstataŭ la necesa funkcieco.
- La tuta fluo de petoj, kiuj venis per la API, povus esti analizita kiel nenio pli ol Nginx aŭ protokolo pri aplikaĵo-servilo. Ĉi tio ne permesis al ni identigi temojn, krom eble de uzantoj kaj abonantoj. Se ne ekzistas maniero reguligi aplikon aŭ klientregistradon, fariĝas neeble analizi la situacion. Ĉi tiu problemo havis la malplej efikon al la evoluo de la API; temas pli pri komprenado de ĝia graveco kaj funkcieco.
Provo numero du: REST API
En 2010, ni provis konstrui interŝanĝan sistemon kun interreta kontado - BukhSoft. Ne ekflugis. Sed dum la integriĝoprocezo, aperis plenrajta API: REST-interŝanĝa servo, kie ne estis liberecoj kiel aliro al operacioj en formo de RPC-vokoj. Ĉiu komunikado kun la API estis alportita al la norma reĝimo por ripozo: la demandlinio enhavas la nomon de la ento, kaj la operacio, kiu estas farita kun ĝi, estas specifita per la http-metodo. Ni aldonis filtradon bazitan sur kiam entoj estis ĝisdatigitaj, kaj uzantoj nun havas la ŝancon konstrui reproduktadon per siaj sistemoj.
En la sama jaro aperis API por malŝarĝo de stokejoj kaj stokregistraj ekvilibroj. La plej valoraj partoj de la sistemo fariĝis haveblaj al uzantoj per API - la interŝanĝo de ĉefaj dokumentoj kaj kalkulitaj datumoj pri ekvilibroj kaj la kosto de varoj.
En decembro 2015, RetailCRM publikigis la unuan triapartan bibliotekon por aliri nian API. Ĝi komencis esti uzata sufiĉe aktive, dum la populareco de la servo entute kreskis, la ŝarĝo sur la API kreskis pli rapide ol la ŝarĝo sur la retinterfaco. Unun tagon kresko fariĝis ŝarĝo pliiĝo.
Kaj ĉi tiu salto, indikita per la sago maldekstre, tute mirigis la servilon servantan nian API. Ni pasigis semajnon por ekscii, kio ĝuste generas ĉi tiun ŝarĝon. Evidentiĝis, ke ĉi tiuj estas la samaj petoj transdonitaj al nia API de la klientfrontoj. Ĉirkaŭ 50 klientoj manĝis ĉion. Ĝuste tiam ni konstatis unu el niaj eraroj - kompleta manko de limoj.
Kiel rezulto, ni enkondukis limon al la nombro da samtempaj petoj. Nun eblas malfermi ne pli ol du petojn samtempe de unu konto. Ĉi tio sufiĉas por labori en reprodukta reĝimo por interŝanĝo de datumoj en bata reĝimo. Kaj tiuj, kiuj volis uzi nin kiel backend, ekde tiu momento, estis devigitaj pli bone plenumi la tarifojn, ĉar ili enkondukis laboron pri pluraj kontoj en sian programaron.
Ni metu ĝin en ordo
Jam ekde 2014, la postulo je la ekzistanta API fariĝis grava parto de la komerco, kaj la API mem generas la plej grandan volumon de datumoj en la interŝanĝo de datumoj kun klientoj. En 2015, ni lanĉis projekton por purigi la API. Ni elektis JSON anstataŭ XML kiel la formaton kaj komencis konstrui ĝin surbaze de la trajtoj kiuj estis identigitaj dum la efektivigo de la antaŭa versio:
- Kapablo administri versiojn. Versiado permesas vin evoluigi novan version sen tuŝi la ekzistantan aplikaĵon aŭ interrompi la uzantan sperton.
- La kapablo por la uzanto vidi metadatenojn en la respondo mem, kiun li ricevas.
- Kapablo interŝanĝi grandajn dokumentojn. Se ni procesas dokumenton kun pli ol 4-5 mil pozicioj, tio fariĝas problemo por la servilo: longa transakcio, longa http-peto. Ni konstruis specialan mekanismon, kiu ebligas al vi ĝisdatigi dokumenton en partoj kaj administri individuajn poziciojn de ĉi tiu dokumento sendante ilin al la servilo.
- Iloj por reproduktado ankaŭ ĉeestis en la antaŭa versio.
- Ŝarĝlimoj estas kiel heredaĵo de la rastilo, kiu estis tretita en la antaŭa versio. Ni enkondukis limojn pri la nombro da petoj en tempodaŭro, la nombro da paralelaj petoj kaj petoj de unu IP-adreso.
Ekde tiam, ni publikigis du malgrandajn versiojn de la API kaj lanĉis plurajn specialigitajn API-ojn, sed la ĝenerala aliro restis senŝanĝa. La ĝisdatigita interŝanĝformato kaj nova arkitekturo ebligis multe pli rapide korekti difektojn en la API.
MySklad API hodiaŭ
Hodiaŭ, la MySklad API solvas multajn problemojn:
- interŝanĝo de datumoj kun interretaj vendejoj, kontadaj sistemoj, bankoj;
- akiri kalkulitajn datumojn kaj raportojn;
- uzu kiel backend por klientaplikoj - niaj moveblaj aplikoj kaj labortabla kasregistrilo funkcias per API
- sendi sciigojn pri datumŝanĝoj en MySklad - rethokoj;
- telefonio;
- lojalecaj sistemoj.
Surbaze de la API, nia CEO Askar Rakhimberdiev en kvar horoj mi skribis telegram-roton kiu tiras restaĵojn tra la API:
Nun sekaj nombroj.
Jen niaj statistikoj por la malnova REST API:
- 400 kompanioj;
- 600 uzantoj;
- 2 milionoj da petoj tage;
- 200 GB/tago de forira trafiko.
Kaj jen kion ni elpensis por ĉiuj MySklad API-oj:
- pli ol 70 integriĝoj (kelkaj el ili videblas ĉi tie );
- 8500 kompanioj;
- 12 uzantoj;
- 46 milionoj da petoj tage;
- 2 TB/tago de forira trafiko.
Kio sekvas
API-disvolvaj planoj estas sub aktiva diskuto. Ni provas konsideri la operacian sperton, kiun la uzantoj provizas al ni. Ne ĉiam eblas fari ĉion samtempe, sed nova versio de la API estas tuj ĉirkaŭ la angulo kun pli oportunaj metadatenoj kaj malpli lanuga strukturo, OAuth por aŭtentigo kaj API por aplikoj enkonstruitaj en la interfaco.
Vi povas sekvi la novaĵojn en speciala retejo por programistoj de integriĝoj kun MySklad: .
fonto: www.habr.com