Birinchi MySklad API 10 yil oldin paydo bo'lgan. Bu vaqt davomida biz API ning mavjud versiyalari ustida ishladik va yangilarini ishlab chiqdik. Va API ning bir nechta versiyalari allaqachon ko'milgan.
Ushbu maqola juda ko'p narsalarni o'z ichiga oladi: API qanday yaratilgan, bulut xizmati nima uchun kerak, u foydalanuvchilarga nima beradi, biz qanday xatolarga yo'l qo'yganmiz va keyin nima qilishni xohlaymiz.
Mening ismim Oleg Alekseev , Men MySklad kompaniyasining texnik direktori va hammuassisiman.
Nima uchun xizmat uchun API yarating
O'n minglab tadbirkorlar bo'lgan mijozlarimiz bulutli echimlardan faol foydalanadilar: bank, onlayn-do'konlar, tovar hisobi, CRM. Biriga ulanganingizdan so'ng, uni to'xtatish qiyin. Va endi beshinchi, sakkizinchi, o'ninchi xizmat tadbirkorning ishini osonlashtiradi, ammo foydalanuvchilar ushbu bulut xizmatlari o'rtasida ma'lumotlarni qo'lda uzatadilar. Ish dahshatli tushga aylanadi.
Aniq yechim foydalanuvchilarga bulutli xizmatlar o'rtasida ma'lumotlarni uzatish imkoniyatini berishdir. Misol uchun, ma'lumotlarni fayl sifatida import va eksport qilish, keyin ularni kerakli xizmatga yuklash mumkin. Fayllar odatda har bir xizmat formatiga mos ravishda o'zgartiriladi. Bu ko'proq yoki kamroq oddiy qo'lda ish, ammo bu xizmatlar sonining ko'payishi bilan uni bajarish tobora qiyinlashib bormoqda.
Shunday qilib, keyingi qadam - bu API. U bilan bulutli xizmat bir vaqtning o'zida bir nechta xizmatlarni ulashidan foyda oladi. Bunday ekotizimning paydo bo'lishi qo'shimcha imkoniyatlar tufayli yangi mijozlarni jalb qiladi. Yangi funksionallikka ega mahsulot yanada foydali va foydali bo'ladi.
Agar siz o'zingizning dasturiy interfeyslaringizni yaratsangiz, bu API tufayli mahsulotingiz haqida biladigan dasturchilar ko'rinishidagi uchinchi tomon sotuvchilarini jalb qiladi. Ular taklif qilingan API asosida yechimlar yaratishni va mijozlarning vazifalarini avtomatlashtirish orqali pul ishlashni boshlaydilar.
MySklad buxgalteriya tizimi oddiy jarayonlarga asoslangan. Asosiysi, birlamchi hujjatlar bilan ishlash, tovarlarni qabul qilish va jo'natish qobiliyati, birlamchi hujjatlar asosida biznes hisobotlarini olish. Shuningdek, ma'lumotlarni bulutli buxgalteriya hisobiga o'tkazish va uni bank tizimlaridan yoki chakana savdo nuqtalaridan olish ham mavjud. Biz onlayn-do'konlar bilan ham ishlaymiz: mahsulotlar haqida ma'lumot olamiz va balanslar haqida ma'lumot yuboramiz.
MySklad-ning birinchi API
MySklad-ning API bilan ishlagan 10 yillik faoliyati davomida biz ma'lumotlar almashish, banklar bilan ishlash, to'lovlarni amalga oshirish va tashqi telefoniyadan foydalanish imkonini beruvchi barcha turdagi integratsiyalarga ega bo'ldik.
Birinchi yilda biz XML formatida istalgan ma'lumotlarni yuklab olish imkoniyatini yaratdik. O'sha paytlarda foydalanuvchilar ma'lumotlarni bulutda emas, balki oflayn rejimda saqlash ancha aniqroq va keng tarqalgan edi va biz ularni ularga berdik. Yuklash interfeysdan qo'lda eksport qilish orqali boshlandi. Ya'ni, uni hali API deb atash mumkin emas edi.
Shu bilan birga, biz Rusagro kompaniyasi bilan hamkorlik qila boshladik - ular allaqachon ishlab chiqarish va sotishni rejalashtirish uchun "kattalar" ERP dan foydalanishgan, ammo ular MySkladdagi zavodlarda mashinalarni yuklashni avtomatlashtirishgan. Shunday qilib, biz haqiqiy API ning birinchi asoslarini oldik: bizning xizmatimiz va ERP o'rtasidagi almashinuv barcha turdagi hujjatlar bo'yicha ma'lumotlarga ega katta faylni yuborish orqali amalga oshirildi.
Bu ommaviy ma'lumotlarni almashish uchun yaxshi variant, lekin hujjatlar bilan bir qatorda biz ularning bog'liqliklarini o'tkazishimiz kerak edi: tovarlar, pudratchilar va omborlar haqida ma'lumot. Eksport paytida bunday axlatni yaratish unchalik qiyin emas, lekin import qilishda uni tahlil qilish juda qiyin, chunki barcha ma'lumotlar bitta paketda keladi: yangi hujjatlar haqida ham, mavjudlari haqida ham.
Birinchi XML API uzoq umr ko'rmadi - ikki yildan keyin biz uni qayta qurishni boshladik. Ishning boshida ham biz dasturiy ta'minot interfeysini yaratishda bir nechta xatolarga yo'l qo'ydik.
XML API qanday yaratilgan: bizning me'morlarimizdan birining illyustratsiyasi. Aytgancha, uning maqolalarini kuzatib boring.
Mana bizning asosiy xatolarimiz:
- JAXB belgilash to'g'ridan-to'g'ri korxona loviyalarida amalga oshirildi. Biz ma'lumotlar bazasi bilan bog'lanish uchun Hibernate-dan foydalanamiz va JAXB belgisi bir xil fasol uchun qilingan. Bu xato deyarli darhol paydo bo'ldi: ma'lumotlar tuzilmasining har qanday yangilanishi API-dan foydalanadigan har bir kishini zudlik bilan xabardor qilish yoki oldingi ma'lumotlar tuzilmasi bilan mosligini ta'minlaydigan tayoqchalarni yaratish zarurligiga olib keldi.
- API qo'shimcha sifatida o'sdi va biz dastlab mahsulotning qaysi qismi ekanligini aniqlamadik. Ular API muhim narsami yoki yo'qmi, birinchi mijozlari uchun orqaga qarab muvofiqlikni saqlab qolish zarurmi yoki yo'qmi haqida o'ylamadilar. Bir vaqtlar API foydalanuvchilari soni kichik sonning taxminan 5% ni tashkil etdi va ularga e'tibor berilmadi. Bir vaqtning o'zida amalga oshirilgan universal filtrlash bizni backend sifatida ishlatishimizga olib keldi. Ushbu filtrlash umuman GraphQL emas edi, lekin shunga o'xshash narsa - u ko'plab so'rovlar qatori parametrlari orqali ishladi. Bunday kuchli vosita bilan foydalanuvchilarga qarshilik ko'rsatish qiyin edi va so'rovlar bizga to'g'ridan-to'g'ri onlayn-do'konlarining UI-dan yuborilishi uchun yuborildi. Vaziyat yoqimsiz ajablanib bo'ldi, chunki bunday xizmatni taqdim etish turli narxlarni va API ning o'zini mahsulot sifatida umuman boshqacha tushunishni talab qilishi kerak.
- API asosiy mahsulot sifatida ishlab chiqilmaganligi sababli, API hujjatlari qoldiq asosida - teskari muhandislik orqali ishlab chiqarilgan va nashr etilgan. Bu yo'l juda oddiy va qulay ko'rinadi, lekin u shartnoma bo'yicha ishlashga zid keladi. Bu oldindan o'rnatilgan operatsion sxemaga ega ma'lum bir komponent mavjud bo'lganda. Ishlab chiquvchi uni ushbu sxema va vazifaga muvofiq amalga oshiradi, komponent sinovdan o'tkaziladi va mijoz tahlilchining fikriga mos keladigan mahsulotni oladi. Teskari muhandislik bozorga oddiygina mavjud bo'lgan mahsulotni chiqaradi: zarur funksionallik o'rniga qo'ltiq tayoqchalari, g'alati echimlar va velosipedlar bilan.
- API orqali kelgan so'rovlarning butun oqimini Nginx yoki dastur serveri jurnalidan boshqa narsa sifatida tahlil qilish mumkin. Bu bizga mavzu sohalarini aniqlashga imkon bermadi, ehtimol foydalanuvchilar va obunachilardan tashqari. Agar ariza yoki mijozni ro'yxatga olishni tartibga solishning iloji bo'lmasa, vaziyatni tahlil qilish imkonsiz bo'ladi. Ushbu muammo API ning rivojlanishiga eng kam ta'sir ko'rsatdi; u ko'proq uning dolzarbligi va funksionalligini tushunishga qaratilgan.
Ikkinchi urinish: REST API
2010 yilda biz onlayn buxgalteriya hisobi bilan birja tizimini - BukhSoft yaratishga harakat qildik. Uchmadi. Ammo integratsiya jarayonida to'liq huquqli API paydo bo'ldi: REST almashinuv xizmati, bu erda RPC qo'ng'iroqlari ko'rinishidagi operatsiyalarga kirish kabi erkinliklar yo'q edi. API bilan barcha aloqalar dam olish uchun standart rejimga keltirildi: so'rovlar qatorida ob'ekt nomi mavjud va u bilan bajariladigan operatsiya http usuli yordamida belgilanadi. Biz ob'ektlar qachon yangilanganiga qarab filtrlashni qo'shdik va endi foydalanuvchilar o'z tizimlari bilan replikatsiya yaratish imkoniyatiga ega.
Xuddi shu yili ombor va inventar qoldiqlarini tushirish uchun API paydo bo'ldi. Tizimning eng qimmatli qismlari API orqali foydalanuvchilar uchun mavjud bo'ldi - birlamchi hujjatlar va balanslar va tovarlar tannarxi bo'yicha hisoblangan ma'lumotlar almashinuvi.
2015-yil dekabr oyida RetailCRM API-ga kirish uchun birinchi uchinchi tomon kutubxonasini nashr etdi. U juda faol qo'llanila boshlandi, umuman olganda xizmatning mashhurligi o'sib borar ekan, API-dagi yuk veb-interfeysdagi yukdan tezroq o'sdi. Bir kunlik o'sish yuk ko'tarilishiga aylandi.
Chapdagi o'q bilan ko'rsatilgan bu sakrash bizning API-ga xizmat ko'rsatadigan serverni hayratda qoldirdi. Biz bu yukni aynan nima keltirib chiqarayotganini aniqlash uchun bir hafta vaqt sarfladik. Ma'lum bo'lishicha, bu bizning API-ga mijozlar tomonidan yuborilgan bir xil so'rovlar. 50 ga yaqin xaridor hamma narsani yeydi. O'shanda biz xatolarimizdan birini angladik - chegaralarning to'liq yo'qligi.
Natijada, biz bir vaqtning o'zida so'rovlar soniga cheklov kiritdik. Endi bitta hisobdan bir vaqtning o'zida ikkitadan ko'p bo'lmagan so'rovlarni ochish mumkin. Bu ommaviy rejimda ma'lumotlar almashinuvi uchun replikatsiya rejimida ishlash uchun etarli. Va bizni backend sifatida ishlatmoqchi bo'lganlar, o'sha paytdan boshlab, tariflarga yaxshiroq rioya qilishga majbur bo'lishdi, chunki ular o'zlarining dasturiy ta'minotiga bir nechta hisoblar bo'yicha ishlarni kiritdilar.
Keling, tartibga keltiraylik
2014 yildan beri mavjud APIga bo'lgan talab biznesning muhim qismiga aylandi va API o'zi mijozlar bilan ma'lumot almashishda eng katta hajmdagi ma'lumotlarni yaratadi. 2015 yilda biz APIni tozalash loyihasini ishga tushirdik. Biz format sifatida XML o'rniga JSON ni tanladik va uni oldingi versiyani amalga oshirish jarayonida aniqlangan xususiyatlar asosida qurishni boshladik:
- Versiyalarni boshqarish qobiliyati. Versiyalash mavjud dasturga ta'sir qilmasdan yoki foydalanuvchi tajribasini buzmasdan yangi versiyani ishlab chiqish imkonini beradi.
- Foydalanuvchi olgan javobning o'zida metama'lumotlarni ko'rish qobiliyati.
- Katta hajmdagi hujjatlarni almashish imkoniyati. Agar biz 4-5 mingdan ortiq pozitsiyaga ega hujjatni qayta ishlasak, bu server uchun muammoga aylanadi: uzoq tranzaksiya, uzoq http so'rovi. Biz hujjatni qismlarga bo'lib yangilash va ularni serverga yuborish orqali ushbu hujjatning alohida pozitsiyalarini boshqarish imkonini beruvchi maxsus mexanizmni yaratdik.
- Replikatsiya uchun vositalar avvalgi versiyada ham mavjud edi.
- Yuklash chegaralari oldingi versiyada bosilgan rake merosiga o'xshaydi. Biz ma'lum vaqt oralig'idagi so'rovlar soniga, parallel so'rovlar soniga va bitta IP-manzildan so'rovlar soniga cheklovlar kiritdik.
O'shandan beri biz APIning ikkita kichik versiyasini chiqardik va bir nechta ixtisoslashtirilgan API-larni ishga tushirdik, ammo umumiy yondashuv o'zgarishsiz qoldi. Yangilangan almashinuv formati va yangi arxitektura APIdagi kamchiliklarni tezroq tuzatishga imkon berdi.
MySklad API bugun
Bugungi kunda MySklad API ko'plab muammolarni hal qiladi:
- onlayn-do'konlar, buxgalteriya tizimlari, banklar bilan ma'lumotlar almashinuvi;
- hisoblangan ma'lumotlar va hisobotlarni olish;
- mijoz ilovalari uchun backend sifatida foydalaning - bizning mobil ilovalarimiz va ish stoli kassa apparati API orqali ishlaydi
- MySklad - webhooks-da ma'lumotlar o'zgarishi haqida bildirishnomalarni yuborish;
- telefoniya;
- sodiqlik tizimlari.
API asosida bosh direktorimiz Asqar Rahimberdiev to'rt soat ichida men API orqali qoldiqlarni olib tashlaydigan telegram botini yozdim:
Endi quruq raqamlar.
Mana eski REST API uchun statistikamiz:
- 400 ta kompaniya;
- 600 foydalanuvchi;
- Kuniga 2 million so'rov;
- 200 GB/kunlik chiquvchi trafik.
Va biz barcha MySklad API-lar uchun nimani o'ylab topdik:
- 70 dan ortiq integratsiya (ularning ba'zilarini bu erda ko'rish mumkin );
- 8500 ta kompaniya;
- 12 000 foydalanuvchi;
- Kuniga 46 million so'rov;
- 2 TB/kunlik chiquvchi trafik.
Keyin nima
APIni rivojlantirish rejalari faol muhokama qilinmoqda. Biz foydalanuvchilarning bizga taqdim etadigan operatsion tajribasini hisobga olishga harakat qilamiz. Hamma narsani bir vaqtning o'zida qilish har doim ham mumkin emas, lekin qulayroq metadata va kamroq bekamu tuzilma, autentifikatsiya uchun OAuth va interfeysga o'rnatilgan ilovalar uchun API bilan APIning yangi versiyasi yaqinda.
Yangiliklarni MySklad bilan integratsiyani ishlab chiquvchilar uchun maxsus veb-saytda kuzatib borishingiz mumkin: .
Manba: www.habr.com
