Ymddangosodd yr API MySklad cyntaf 10 mlynedd yn ôl. Trwy'r amser hwn rydym wedi bod yn gweithio ar fersiynau presennol o'r API ac yn datblygu rhai newydd. Ac mae sawl fersiwn o'r API eisoes wedi'u claddu.
Bydd yr erthygl hon yn cynnwys llawer o bethau: sut y crëwyd yr API, pam mae ei angen ar y gwasanaeth cwmwl, beth mae'n ei roi i ddefnyddwyr, pa gamgymeriadau y gwnaethom lwyddo i gamu ymlaen a beth rydym am ei wneud nesaf.
Fy enw i yw Oleg Alekseev , Fi yw cyfarwyddwr technegol a chyd-sylfaenydd MySklad.
Pam gwneud API ar gyfer gwasanaeth
Mae ein cleientiaid, sef degau o filoedd o entrepreneuriaid, yn defnyddio datrysiadau cwmwl yn weithredol: bancio, siopau ar-lein, cyfrifyddu nwyddau, CRM. Unwaith y byddwch chi'n cysylltu ag un, mae'n anodd stopio. Ac yn awr mae'r pumed, wythfed, degfed gwasanaeth yn gwneud gwaith yr entrepreneur yn haws, ond mae defnyddwyr yn trosglwyddo data rhwng y gwasanaethau cwmwl hyn â llaw. Mae gwaith yn troi'n hunllef.
Yr ateb amlwg yw rhoi'r gallu i ddefnyddwyr drosglwyddo data rhwng gwasanaethau cwmwl. Er enghraifft, mewnforio ac allforio data fel ffeiliau, y gellir eu huwchlwytho wedyn i'r gwasanaeth a ddymunir. Fel arfer caiff ffeiliau eu newid i gyd-fynd â fformat pob gwasanaeth. Mae hyn fwy neu lai yn waith llaw syml, ond gyda'r cynnydd yn nifer y gwasanaethau hyn, mae'n dod yn fwyfwy anodd ei berfformio.
Felly, y cam nesaf yw'r API. Ag ef, mae'r gwasanaeth cwmwl yn elwa o'r ffaith ei fod yn cysylltu sawl gwasanaeth ar un adeg. Mae ymddangosiad ecosystem o'r fath yn denu cwsmeriaid newydd oherwydd cyfleoedd ychwanegol. Mae cynnyrch ag ymarferoldeb newydd yn dod yn fwy proffidiol a defnyddiol.
Os ydych chi'n creu eich rhyngwynebau rhaglennu eich hun, mae hyn yn denu gwerthwyr trydydd parti ar ffurf rhaglenwyr sy'n gwybod am eich cynnyrch diolch i'r API. Maent yn dechrau adeiladu atebion yn seiliedig ar yr API arfaethedig ac yn gwneud arian trwy awtomeiddio tasgau eu cwsmeriaid.
Mae system gyfrifo MySklad yn seiliedig ar brosesau syml. Y prif beth yw gweithio gyda dogfennau cynradd, y gallu i dderbyn a chludo nwyddau, a derbyn adroddiadau busnes yn seiliedig ar ddogfennau cynradd. Mae data hefyd yn cael ei drosglwyddo, er enghraifft i gyfrifo cwmwl, a'i dderbyn o systemau bancio neu allfeydd manwerthu. Rydym hefyd yn gweithio gyda siopau ar-lein: rydym yn derbyn gwybodaeth am gynhyrchion ac yn anfon gwybodaeth am falansau.
API cyntaf MySklad
Dros y 10 mlynedd o MySklad yn gweithio gydag API, rydym wedi caffael pob math o integreiddiadau sy'n ein galluogi i gyfnewid data, gweithio gyda banciau, gwneud taliadau a defnyddio teleffoni allanol.
Yn y flwyddyn gyntaf, gwnaethom hi'n bosibl lawrlwytho unrhyw ddata ar fformat XML. Yn ôl wedyn, roedd yn llawer cliriach ac yn fwy cyffredin i ddefnyddwyr gadw data all-lein, yn hytrach nag mewn rhywfaint o gwmwl, a gwnaethom ei roi iddynt. Dechreuwyd y llwytho i fyny trwy allforio â llaw o'r rhyngwyneb. Hynny yw, ni ellid ei alw'n API eto.
Ar yr un pryd, fe ddechreuon ni gydweithio â chwmni Rusagro - roedden nhw eisoes yn defnyddio ERP “oedolyn” ar gyfer cynllunio cynhyrchu a gwerthu, ond fe wnaethon nhw awtomeiddio llwytho ceir mewn ffatrïoedd yn MySklad. Dyma sut y cawsom yr elfennau cyntaf o API go iawn: digwyddodd y cyfnewid rhwng ein gwasanaeth ac ERP trwy anfon ffeil fawr gyda data ar bob math o ddogfennau.
Mae hwn yn opsiwn da ar gyfer cyfnewid data swp, ond ynghyd â dogfennau roedd yn rhaid i ni drosglwyddo eu dibyniaethau: gwybodaeth am nwyddau, contractwyr a warysau. Nid yw domen o'r fath mor anodd ei gynhyrchu wrth allforio, ond mae'n eithaf anodd ei ddosrannu wrth fewnforio, gan fod yr holl wybodaeth yn dod mewn un pecyn: am ddogfennau newydd ac am y rhai presennol.
Nid oedd yr API XML cyntaf yn byw yn hir - ddwy flynedd yn ddiweddarach dechreuon ni ei ailadeiladu. Hyd yn oed ar ddechrau ei waith, gwnaethom sawl camgymeriad wrth adeiladu'r rhyngwyneb meddalwedd.
Sut y gwnaed yr API XML: darlun gan un o'n penseiri. Gyda llaw, cadwch draw am ei erthyglau.
Dyma ein prif gamgymeriadau:
- Gwnaed marcio JAXB yn uniongyrchol ar ffa endid. Rydym yn defnyddio gaeafgysgu i gyfathrebu â'r gronfa ddata, a gwnaed marcio JAXB ar gyfer yr un ffa. Ymddangosodd y gwall hwn bron ar unwaith: arweiniodd unrhyw ddiweddariad i'r strwythur data at yr angen i hysbysu pawb sy'n defnyddio'r API ar frys, neu i adeiladu baglau a fyddai'n sicrhau cydnawsedd â'r strwythur data blaenorol.
- Tyfodd yr API fel ychwanegiad, ac ni wnaethom ddiffinio i ddechrau pa ran o'r cynnyrch ydoedd. Nid oeddent yn meddwl a oedd yr API yn rhywbeth pwysig neu a oedd angen cynnal cydnawsedd yn ôl ar gyfer ei gleientiaid cyntaf. Ar un adeg, roedd nifer y defnyddwyr API tua 5% o'r nifer fach, ac ni thalwyd unrhyw sylw iddynt. Arweiniodd y hidlo cyffredinol a wnaed ar un adeg at ein defnyddio fel backend. Nid oedd y hidlo hwn yn GraphQL o gwbl, ond rhywbeth felly - fe weithiodd trwy lawer o baramedrau llinyn ymholiad. Gydag offeryn mor bwerus, roedd yn anodd i ddefnyddwyr wrthsefyll, a throsglwyddwyd ceisiadau i ni fel eu bod yn cael eu hanfon yn uniongyrchol o UI eu siopau ar-lein. Roedd y sefyllfa'n syndod annymunol, oherwydd dylai darparu gwasanaeth o'r fath ofyn am brisiau gwahanol a dealltwriaeth gyffredinol wahanol o'r API ei hun fel cynnyrch.
- Oherwydd y ffaith na ddatblygwyd yr API fel prif gynnyrch, cynhyrchwyd dogfennaeth API a'i gyhoeddi ar sail weddilliol - trwy beirianneg wrthdroi. Mae'r llwybr hwn yn ymddangos yn eithaf syml a chyfleus, ond mae'n gwrth-ddweud gweithio o dan gontract. Dyma pan fydd elfen benodol gyda chynllun gweithredu rhagosodedig. Mae'r datblygwr yn ei weithredu yn unol â'r cynllun a'r dasg hon, mae'r gydran yn cael ei brofi, ac mae'r cleient yn derbyn cynnyrch sy'n cyd-fynd â syniad y dadansoddwr. Mae peirianneg wrthdro yn taflu cynnyrch sy'n bodoli'n syml i'r farchnad: gyda baglau, atebion rhyfedd a beiciau yn lle'r ymarferoldeb angenrheidiol.
- Gellid dadansoddi'r llif cyfan o geisiadau a ddaeth trwy'r API fel dim mwy na log gweinydd Nginx neu gais. Nid oedd hyn yn caniatáu i ni nodi meysydd pwnc, ac eithrio efallai gan ddefnyddwyr a thanysgrifwyr. Os nad oes unrhyw ffordd i reoleiddio cais neu gofrestriad cleient, mae'n dod yn amhosibl dadansoddi'r sefyllfa. Y broblem hon a gafodd yr effaith leiaf ar ddatblygiad yr API;
Cais rhif dau: REST API
Yn 2010, fe wnaethom geisio adeiladu system gyfnewid gyda chyfrifo ar-lein - BukhSoft. Heb gymryd i ffwrdd. Ond yn ystod y broses integreiddio, ymddangosodd API llawn: gwasanaeth cyfnewid REST, lle nad oedd unrhyw ryddid fel cyrchu gweithrediadau ar ffurf galwadau RPC. Daethpwyd â'r holl gyfathrebu â'r API i'r modd safonol ar gyfer gorffwys: mae'r llinell ymholiad yn cynnwys enw'r endid, a nodir y gweithrediad a gyflawnir ag ef gan ddefnyddio'r dull http. Fe wnaethom ychwanegu hidlo yn seiliedig ar bryd y cafodd endidau eu diweddaru, ac mae defnyddwyr nawr yn cael y cyfle i adeiladu atgynhyrchu gyda'u systemau.
Yn yr un flwyddyn, ymddangosodd API ar gyfer dadlwytho balansau warws a rhestr eiddo. Mae rhannau mwyaf gwerthfawr y system wedi dod ar gael i ddefnyddwyr trwy API - cyfnewid dogfennau cynradd a data wedi'i gyfrifo ar falansau a chost nwyddau.
Ym mis Rhagfyr 2015, cyhoeddodd RetailCRM y llyfrgell trydydd parti gyntaf i gael mynediad at ein API. Dechreuwyd ei ddefnyddio'n eithaf gweithredol, tra bod poblogrwydd y gwasanaeth yn ei gyfanrwydd yn tyfu, tyfodd y llwyth ar yr API yn gyflymach na'r llwyth ar y rhyngwyneb gwe. Trodd twf un diwrnod yn ymchwydd llwyth.
Ac roedd y naid hon, a nodir gan y saeth ar y chwith, yn rhyfeddu'n llwyr y gweinydd sy'n gwasanaethu ein API. Treulion ni wythnos yn darganfod beth yn union oedd yn cynhyrchu'r llwyth hwn. Daeth i'r amlwg mai'r un ceisiadau yw'r rhain a drosglwyddwyd i'n API o flaen y cleient. Roedd tua 50 o gwsmeriaid yn bwyta popeth. Dyna pryd y sylweddolon ni un o'n camgymeriadau - diffyg terfynau llwyr.
O ganlyniad, cyflwynwyd terfyn ar nifer y ceisiadau cydamserol. Bellach nid oes modd agor mwy na dau gais ar yr un pryd o un cyfrif. Mae hyn yn ddigon i weithio yn y modd atgynhyrchu ar gyfer cyfnewid data yn y modd swp. Ac o'r eiliad honno ymlaen, gorfodwyd y rhai a oedd am ein defnyddio fel backend i gydymffurfio'n well â'r tariffau, gan iddynt gyflwyno gwaith ar sawl cyfrif i'w meddalwedd.
Gadewch i ni ei roi mewn trefn
Eisoes ers 2014, mae'r galw am yr API presennol wedi dod yn rhan bwysig o'r busnes, ac mae'r API ei hun yn cynhyrchu'r cyfaint mwyaf o ddata wrth gyfnewid data gyda chleientiaid. Yn 2015, fe wnaethom lansio prosiect i lanhau'r API. Fe wnaethom ddewis JSON yn lle XML fel y fformat a dechrau ei adeiladu yn seiliedig ar y nodweddion a nodwyd yn ystod gweithredu'r fersiwn flaenorol:
- Y gallu i reoli fersiynau. Mae fersiynau yn eich galluogi i ddatblygu fersiwn newydd heb effeithio ar y cymhwysiad presennol nac amharu ar brofiad y defnyddiwr.
- Y gallu i'r defnyddiwr weld metadata yn yr ymateb ei hun y mae'n ei dderbyn.
- Y gallu i gyfnewid dogfennau mawr. Os byddwn yn prosesu dogfen gyda mwy na 4-5 mil o swyddi, mae hyn yn dod yn broblem i'r gweinydd: trafodiad hir, cais http hir. Fe wnaethom adeiladu mecanwaith arbennig sy'n eich galluogi i ddiweddaru dogfen mewn rhannau a rheoli safleoedd unigol y ddogfen hon trwy eu hanfon at y gweinydd.
- Roedd offer atgynhyrchu hefyd yn bresennol yn y fersiwn flaenorol.
- Mae terfynau llwyth yn debyg i etifeddiaeth y rhaca y camwyd ymlaen yn y fersiwn flaenorol. Cyflwynwyd cyfyngiadau ar nifer y ceisiadau mewn cyfnod o amser, nifer y ceisiadau cyfochrog a cheisiadau o un cyfeiriad IP.
Ers hynny, rydym wedi rhyddhau dwy fersiwn fach o'r API ac wedi lansio sawl API arbenigol, ond nid yw'r dull gweithredu cyffredinol wedi newid. Roedd y fformat cyfnewid wedi'i ddiweddaru a'r bensaernïaeth newydd yn ei gwneud hi'n bosibl cywiro diffygion yn yr API yn llawer cyflymach.
MySklad API heddiw
Heddiw, mae API MySklad yn datrys llawer o broblemau:
- cyfnewid data gyda siopau ar-lein, systemau cyfrifo, banciau;
- cael data ac adroddiadau wedi'u cyfrifo;
- defnyddio fel backend ar gyfer ceisiadau cleient - mae ein cymwysiadau symudol a chofrestr arian bwrdd gwaith yn gweithio trwy API
- anfon hysbysiadau am newidiadau data yn MySklad - bachau gwe;
- teleffoni;
- systemau teyrngarwch.
Yn seiliedig ar yr API, ein Prif Swyddog Gweithredol Askar Rakhimberdiev mewn pedair awr ysgrifennais bot telegram sy'n tynnu bwyd dros ben trwy'r API:
Nawr niferoedd sych.
Dyma ein hystadegau ar gyfer yr hen API REST:
- 400 o gwmnïau;
- 600 o ddefnyddwyr;
- 2 filiwn o geisiadau y dydd;
- 200 GB y dydd o draffig sy'n mynd allan.
A dyma beth wnaethon ni feddwl amdano ar gyfer yr holl APIs MySklad:
- mwy na 70 o integreiddiadau (gellir gweld rhai ohonynt yma );
- 8500 o gwmnïau;
- 12 o ddefnyddwyr;
- 46 filiwn o geisiadau y dydd;
- 2 TB/diwrnod o draffig yn mynd allan.
Beth sydd nesaf
Mae cynlluniau datblygu API yn cael eu trafod yn weithredol. Rydym yn ceisio cymryd i ystyriaeth y profiad gweithredu y mae defnyddwyr yn ei ddarparu i ni. Nid yw bob amser yn bosibl gwneud popeth ar unwaith, ond mae fersiwn newydd o'r API rownd y gornel gyda metadata mwy cyfleus a strwythur llai blewog, OAuth ar gyfer dilysu, ac API ar gyfer cymwysiadau sydd wedi'u hymgorffori yn y rhyngwyneb.
Gallwch ddilyn y newyddion ar wefan arbennig ar gyfer datblygwyr integreiddiadau gyda MySklad: .
Ffynhonnell: hab.com
