İlk MySklad API 10 il əvvəl ortaya çıxdı. Bütün bu müddət ərzində biz API-nin mövcud versiyaları üzərində işləyirik və yenilərini inkişaf etdiririk. Və API-nin bir neçə versiyası artıq basdırılıb.
Bu məqalədə çox şey olacaq: API necə yaradılıb, bulud xidmətinə niyə ehtiyac var, istifadəçilərə nə verir, hansı səhvlərə yol vermişik və bundan sonra nə etmək istəyirik.
Mənim adım Oleq Alekseevdir , Mən MySklad-ın texniki direktoru və həmtəsisçisiyəm.
Niyə bir xidmət üçün API yaradın?
On minlərlə sahibkar olan müştərilərimiz bulud həllərindən fəal şəkildə istifadə edirlər: bankçılıq, onlayn mağazalar, malların uçotu, CRM. Birinə qoşulduqdan sonra dayandırmaq çətindir. İndi beşinci, səkkizinci, onuncu xidmət sahibkarın işini asanlaşdırır, lakin istifadəçilər bu bulud xidmətləri arasında məlumatları əl ilə ötürürlər. İş kabusa çevrilir.
Açıq həll yolu istifadəçilərə bulud xidmətləri arasında məlumat ötürmək imkanı verməkdir. Məsələn, məlumatları fayl kimi idxal və ixrac edin, sonra onları istədiyiniz xidmətə yükləmək olar. Fayllar adətən hər bir xidmətin formatına uyğun olaraq dəyişdirilir. Bu, az-çox sadə əl işidir, lakin bu xidmətlərin sayının artması ilə yerinə yetirilməsi getdikcə çətinləşir.
Beləliklə, növbəti addım API-dir. Onunla bulud xidməti bir anda bir neçə xidməti birləşdirməsindən faydalanır. Belə bir ekosistemin yaranması əlavə imkanlar hesabına yeni müştəriləri cəlb edir. Yeni funksionallığı olan məhsul daha sərfəli və faydalı olur.
Öz proqramlaşdırma interfeyslərinizi yaratsanız, bu, API sayəsində məhsulunuz haqqında bilən proqramçılar şəklində üçüncü tərəfin satış adamlarını cəlb edir. Onlar təklif olunan API əsasında həllər yaratmağa və müştərilərinin tapşırıqlarını avtomatlaşdıraraq pul qazanmağa başlayırlar.
MySklad mühasibat sistemi sadə proseslərə əsaslanır. Əsas odur ki, ilkin sənədlərlə işləmək, malların qəbulu və göndərilməsi bacarığı, ilkin sənədlər əsasında biznes hesabatlarının alınmasıdır. Məlumatların, məsələn, bulud uçotuna ötürülməsi və bank sistemlərindən və ya pərakəndə satış məntəqələrindən alınması da var. Biz həmçinin onlayn mağazalarla işləyirik: məhsullar haqqında məlumat alırıq və balanslar haqqında məlumat göndəririk.
MySklad-ın ilk API-si
MySklad-ın API ilə işlədiyi 10 il ərzində biz məlumat mübadiləsinə, banklarla işləməyə, ödənişlər etməyə və xarici telefoniyadan istifadə etməyə imkan verən bütün növ inteqrasiyalar əldə etmişik.
Birinci ildə biz istənilən məlumatı XML formatında yükləməyi mümkün etdik. O vaxtlar istifadəçilər üçün məlumatları bəzi buludda deyil, oflayn saxlamaq daha aydın və daha adi idi və biz onları onlara verdik. Yükləmə interfeysdən əl ilə ixrac etməklə başladı. Yəni onu hələ API adlandırmaq olmazdı.
Eyni zamanda, biz Rusagro şirkəti ilə əməkdaşlığa başladıq - onlar istehsal və satışın planlaşdırılması üçün artıq "böyüklər" ERP-dən istifadə edirdilər, lakin MySkladdakı fabriklərdə avtomobillərin yüklənməsini avtomatlaşdırdılar. Həqiqi API-nin ilk əsaslarını belə əldə etdik: xidmətimizlə ERP arasında mübadilə bütün növ sənədlərə dair məlumatları olan böyük bir fayl göndərməklə baş verdi.
Bu, toplu məlumat mübadiləsi üçün yaxşı seçimdir, lakin sənədlərlə yanaşı, onların asılılıqlarını da ötürməli olduq: mallar, podratçılar və anbarlar haqqında məlumat. İxrac edərkən belə bir zibil yaratmaq o qədər də çətin deyil, idxal edərkən təhlil etmək olduqca çətindir, çünki bütün məlumatlar bir paketdə gəlir: həm yeni sənədlər, həm də mövcud olanlar haqqında.
İlk XML API uzun müddət yaşamadı - iki ildən sonra biz onu yenidən qurmağa başladıq. Hətta onun işinin başlanğıcında biz proqram interfeysini qurarkən bir sıra səhvlərə yol verdik.
XML API necə hazırlanmışdır: memarlarımızdan birinin təsviri. Yeri gəlmişkən, onun məqalələrini izləməyə davam edin.
Əsas səhvlərimiz bunlardır:
- JAXB işarələməsi birbaşa müəssisə lobya üzərində edildi. Verilənlər bazası ilə əlaqə saxlamaq üçün Hibernate-dən istifadə edirik və JAXB işarələməsi eyni lobya üçün hazırlanmışdır. Bu səhv demək olar ki, dərhal ortaya çıxdı: məlumat strukturunun hər hansı bir yeniləməsi API-dən istifadə edən hər kəsə təcili məlumat vermək və ya əvvəlki məlumat strukturu ilə uyğunluğu təmin edən qoltuqağaqlar yaratmaq ehtiyacına səbəb oldu.
- API əlavə olaraq böyüdü və biz onun məhsulun hansı hissəsi olduğunu əvvəlcə müəyyən etmədik. API-nin vacib bir şey olub-olmaması, ilk müştəriləri üçün geriyə uyğunluğu qorumaq lazım olub-olmaması barədə düşünmürdülər. Bir vaxtlar API istifadəçilərinin sayı kiçik sayın təxminən 5%-ni təşkil edirdi və onlara diqqət yetirilmirdi. Bir vaxtlar edilən universal filtrləmə bizi arxa plan kimi istifadə etməyimizə səbəb oldu. Bu filtrləmə ümumiyyətlə GraphQL deyildi, lakin buna bənzər bir şey - bir çox sorğu sətri parametrləri ilə işləyirdi. Belə güclü bir vasitə ilə istifadəçilərin müqavimət göstərməsi çətin idi və sorğular bizə ötürülürdü ki, onlar birbaşa onlayn mağazalarının UI-dən göndərilirdi. Vəziyyət xoşagəlməz bir sürpriz oldu, çünki belə bir xidmətin göstərilməsi fərqli qiymətlər və API-nin özünün bir məhsul kimi ümumiyyətlə fərqli başa düşülməsini tələb etməlidir.
- API əsas məhsul kimi hazırlanmadığına görə API sənədləri qalıq əsasda - tərs mühəndislik yolu ilə hazırlanaraq dərc edilib. Bu yol kifayət qədər sadə və rahat görünür, lakin müqavilə əsasında işləməyə ziddir. Bu, əvvəlcədən təyin edilmiş əməliyyat sxemi ilə müəyyən bir komponent olduqda. Tərtibatçı onu bu sxemə və tapşırığa uyğun həyata keçirir, komponent sınaqdan keçirilir və müştəri analitikin fikrinə uyğun məhsul alır. Əks mühəndislik bazara sadəcə mövcud olan məhsulu təqdim edir: lazımi funksionallıq əvəzinə qoltuqağaqları, qəribə həllər və velosipedlərlə.
- API vasitəsilə gələn bütün sorğu axını Nginx və ya proqram server jurnalından başqa bir şey kimi təhlil edilə bilər. Bu, istifadəçilər və abunəçilər istisna olmaqla, mövzu sahələrini müəyyən etməyə imkan vermədi. Ərizə və ya müştəri qeydiyyatını tənzimləmək üçün heç bir yol yoxdursa, vəziyyəti təhlil etmək qeyri-mümkün olur. Bu problem API-nin inkişafına ən az təsir etdi; bu, daha çox onun aktuallığını və funksionallığını başa düşməkdən ibarətdir.
İkinci cəhd: REST API
2010-cu ildə biz onlayn mühasibat uçotu ilə mübadilə sistemi qurmağa çalışdıq - BukhSoft. Uçmadı. Lakin inteqrasiya prosesi zamanı tam hüquqlu API peyda oldu: REST mübadilə xidməti, burada RPC zəngləri şəklində əməliyyatlara daxil olmaq kimi azadlıqlar yox idi. API ilə bütün əlaqə istirahət üçün standart rejimə gətirildi: sorğu sətirində obyektin adı var və onunla həyata keçirilən əməliyyat http metodu ilə müəyyən edilir. Müəssisələrin yeniləndiyi vaxt əsasında filtrləmə əlavə etdik və istifadəçilərin indi öz sistemləri ilə replikasiya yaratmaq imkanı var.
Elə həmin il anbar və inventar qalıqlarının boşaldılması üçün API meydana çıxdı. Sistemin ən dəyərli hissələri API vasitəsilə istifadəçilər üçün əlçatan olub - ilkin sənədlərin və qalıqlar və malların dəyəri haqqında hesablanmış məlumatların mübadiləsi.
2015-ci ilin dekabrında RetailCRM API-yə daxil olmaq üçün ilk üçüncü tərəf kitabxanasını nəşr etdi. O, kifayət qədər fəal şəkildə istifadə olunmağa başladı, bütövlükdə xidmətin populyarlığı artarkən, API-dəki yük veb-interfeysdəki yükdən daha sürətli artdı. Bir gün artım yük artımına çevrildi.
Və soldakı ox ilə göstərilən bu sıçrayış API-mizə xidmət edən serveri tamamilə heyran etdi. Bu yükü tam olaraq nəyin yaratdığını anlamaq üçün bir həftə sərf etdik. Məlum oldu ki, bunlar müştəri cəbhələrindən API-mizə ötürülən eyni sorğulardır. 50-yə yaxın müştəri hər şeyi yedi. Məhz o zaman biz öz səhvlərimizdən birini anladıq - limitlərin tam olmaması.
Nəticədə, biz eyni vaxtda sorğuların sayına məhdudiyyət tətbiq etdik. İndi bir hesabdan eyni vaxtda ikidən çox sorğu açmaq mümkündür. Bu, toplu rejimdə məlumat mübadiləsi üçün təkrarlama rejimində işləmək üçün kifayətdir. Və bizdən backend kimi istifadə etmək istəyənlər, o andan etibarən tariflərə daha yaxşı uyğunlaşmaq məcburiyyətində qaldılar, çünki onlar proqramlarına bir neçə hesabda iş təqdim etdilər.
Gəlin qaydaya salaq
Artıq 2014-cü ildən mövcud API-yə tələbat biznesin mühüm hissəsinə çevrilib və API özü müştərilərlə məlumat mübadiləsi zamanı ən böyük həcmdə məlumat yaradır. 2015-ci ildə biz API-nin təmizlənməsi layihəsinə başladıq. Format olaraq XML əvəzinə JSON-u seçdik və onu əvvəlki versiyanın tətbiqi zamanı müəyyən edilmiş xüsusiyyətlər əsasında qurmağa başladıq:
- Versiyaları idarə etmək bacarığı. Versiyalaşdırma, mövcud proqrama təsir etmədən və ya istifadəçi təcrübəsini pozmadan yeni versiya hazırlamağa imkan verir.
- İstifadəçinin aldığı cavabın özündə metadata görmək imkanı.
- Böyük sənədlərin mübadiləsi imkanı. 4-5 mindən çox mövqeyə malik bir sənədi emal etsək, bu, server üçün problemə çevrilir: uzun bir əməliyyat, uzun http sorğusu. Sənədi hissə-hissə yeniləməyə və bu sənədin ayrı-ayrı mövqelərini serverə göndərməklə idarə etməyə imkan verən xüsusi mexanizm yaratdıq.
- Replikasiya üçün alətlər də əvvəlki versiyada mövcud idi.
- Yük məhdudiyyətləri əvvəlki versiyada basılan dırmıq mirası kimidir. Müəyyən bir müddət ərzində sorğuların sayına, paralel sorğuların sayına və bir IP ünvanından sorğulara məhdudiyyətlər tətbiq etdik.
O vaxtdan bəri biz API-nin iki kiçik versiyasını buraxdıq və bir neçə ixtisaslaşmış API-ni işə saldıq, lakin ümumi yanaşma dəyişməz olaraq qaldı. Yenilənmiş mübadilə formatı və yeni arxitektura API-dəki qüsurları daha tez düzəltməyə imkan verdi.
MySklad API bu gün
Bu gün MySklad API bir çox problemləri həll edir:
- onlayn mağazalar, mühasibat sistemləri, banklar ilə məlumat mübadiləsi;
- hesablanmış məlumatların və hesabatların əldə edilməsi;
- müştəri proqramları üçün backend kimi istifadə edin - mobil proqramlarımız və masa üstü kassa aparatı API vasitəsilə işləyir
- MySklad-da məlumat dəyişiklikləri haqqında bildirişlərin göndərilməsi - webhooks;
- telefoniya;
- loyallıq sistemləri.
API əsasında baş direktorumuz Əsgər Rəhimbərdiyev dörd saat ərzində API vasitəsilə qalıqları çəkən teleqram botu yazdım:
İndi quru nömrələr.
Budur köhnə REST API üçün statistikamız:
- 400 şirkət;
- 600 istifadəçi;
- Gündə 2 milyon sorğu;
- 200 GB/gün gedən trafik.
Bütün MySklad API-ləri üçün hazırladığımız budur:
- 70-dən çox inteqrasiya (onlardan bəzilərinə burada baxmaq olar );
- 8500 şirkət;
- 12 istifadəçi;
- Gündə 46 milyon sorğu;
- 2 TB/gün gedən trafik.
Nədir?
API inkişaf planları fəal müzakirə olunur. Biz istifadəçilərin bizə təqdim etdiyi əməliyyat təcrübəsini nəzərə almağa çalışırıq. Hər şeyi bir anda etmək həmişə mümkün deyil, lakin API-nin yeni versiyası daha rahat metadata və daha az tüklü struktur, autentifikasiya üçün OAuth və interfeysə quraşdırılmış tətbiqlər üçün API ilə yaxındadır.
Xəbərləri MySklad ilə inteqrasiya tərtibatçıları üçün xüsusi veb saytında izləyə bilərsiniz: .
Mənbə: www.habr.com