បានសរសេរ API - ហែក XML (ពីរ)

MyWarehouse API ដំបូងបានបង្ហាញខ្លួនកាលពី 10 ឆ្នាំមុន។ គ្រប់ពេលវេលានេះ យើងកំពុងធ្វើការលើកំណែ API ដែលមានស្រាប់ និងអភិវឌ្ឍថ្មី។ ហើយកំណែជាច្រើននៃ API ត្រូវបានកប់រួចហើយ។

អត្ថបទនេះនឹងគ្របដណ្តប់លើរឿងជាច្រើន៖ របៀបដែល API ត្រូវបានបង្កើតឡើង ហេតុអ្វីបានជាសេវាកម្មពពកត្រូវការវា អ្វីដែលវាផ្តល់ឱ្យអ្នកប្រើប្រាស់ កំហុសអ្វីខ្លះដែលយើងបានធ្វើ និងអ្វីដែលយើងចង់ធ្វើបន្ទាប់ទៀត។

ខ្ញុំឈ្មោះ Oleg Alekseev oalexeevខ្ញុំជានាយកបច្ចេកទេស និងជាសហស្ថាបនិកនៃ MyWarehouse ។

ហេតុអ្វីបានជាបង្កើត API សម្រាប់សេវាកម្ម

អតិថិជនរបស់យើង ដែលរាប់បញ្ចូលទាំងសហគ្រិនរាប់ម៉ឺននាក់ ប្រើប្រាស់យ៉ាងសកម្មនូវដំណោះស្រាយលើពពក៖ ធនាគារ ហាងអនឡាញ ការគ្រប់គ្រងសារពើភ័ណ្ឌ CRM ។ ភ្ជាប់ទៅមួយហើយវាពិបាកក្នុងការបញ្ឈប់។ ហើយឥឡូវនេះសេវាទីប្រាំ ទីប្រាំបី ទីដប់ធ្វើឱ្យការងាររបស់សហគ្រិនកាន់តែងាយស្រួល ប៉ុន្តែអ្នកប្រើប្រាស់ផ្ទេរទិន្នន័យរវាងសេវាកម្មពពកទាំងនេះដោយដៃ។ ការងារកំពុងក្លាយជាសុបិន្តអាក្រក់។

ដំណោះស្រាយជាក់ស្តែងគឺផ្តល់ឱ្យអ្នកប្រើប្រាស់នូវសមត្ថភាពក្នុងការផ្ទេរទិន្នន័យរវាងសេវាកម្មពពក។ ឧទាហរណ៍ នាំចូល និងនាំចេញទិន្នន័យជាឯកសារ ដែលបន្ទាប់មកអាចត្រូវបានផ្ទុកឡើងទៅកាន់សេវាកម្មដែលចង់បាន។ ឯកសារត្រូវបានផ្លាស់ប្តូរជាធម្មតាដើម្បីឱ្យសមនឹងទម្រង់នៃសេវាកម្មនីមួយៗ។ នេះជាការងារដោយដៃសាមញ្ញច្រើន ឬតិច ប៉ុន្តែនៅពេលដែលចំនួនសេវាកម្មទាំងនេះកើនឡើង វាកាន់តែពិបាកធ្វើ។

ដូច្នេះជំហានបន្ទាប់គឺ API ។ ជាមួយវា សេវាកម្មពពកទទួលបានអត្ថប្រយោជន៍ពីការភ្ជាប់សេវាកម្មជាច្រើននៅកន្លែងតែមួយ។ ការលេចឡើងនៃប្រព័ន្ធអេកូឡូស៊ីបែបនេះទាក់ទាញអតិថិជនថ្មីដោយសារតែឱកាសបន្ថែម។ ផលិតផលដែលមានមុខងារថ្មីកាន់តែទទួលបានផលចំណេញ និងមានប្រយោជន៍។

ការបង្កើត APIs ផ្ទាល់ខ្លួនរបស់អ្នកទាក់ទាញអ្នកលក់ភាគីទីបីក្នុងទម្រង់ជាអ្នកសរសេរកម្មវិធីដែលដឹងអំពីផលិតផលរបស់អ្នកតាមរយៈ API ។ ពួកគេចាប់ផ្តើមបង្កើតដំណោះស្រាយដោយផ្អែកលើ API ដែលបានស្នើឡើង និងរកប្រាក់ដោយស្វ័យប្រវត្តិកម្មភារកិច្ចរបស់អតិថិជនរបស់ពួកគេ។

ប្រព័ន្ធគណនេយ្យរបស់ MyWarehouse គឺផ្អែកលើដំណើរការសាមញ្ញ។ រឿងសំខាន់គឺធ្វើការជាមួយឯកសារបឋម សមត្ថភាពក្នុងការទទួលយក និងដឹកជញ្ជូនទំនិញ និងទទួលរបាយការណ៍សម្រាប់អាជីវកម្មដោយផ្អែកលើឯកសារបឋម។ ក៏មានការផ្ទេរទិន្នន័យផងដែរ ឧទាហរណ៍ទៅគណនីពពក និងការទទួលរបស់វាពីប្រព័ន្ធធនាគារ ឬហាងលក់រាយ។ យើងក៏ធ្វើការជាមួយហាងអនឡាញផងដែរ៖ យើងទទួលបានព័ត៌មានអំពីផលិតផល និងផ្ញើទិន្នន័យអំពីសមតុល្យ។

API ដំបូងរបស់ MyWarehouse

ក្នុងរយៈពេល 10 ឆ្នាំនៃការងាររបស់ MyWarehouse ជាមួយ API យើងបានទទួលការរួមបញ្ចូលគ្រប់ប្រភេទដែលអនុញ្ញាតឱ្យយើងផ្លាស់ប្តូរទិន្នន័យ ធ្វើការជាមួយធនាគារ ទូទាត់ប្រាក់ និងប្រើប្រាស់ទូរស័ព្ទខាងក្រៅ។

ក្នុងឆ្នាំដំបូង យើងបានធ្វើឱ្យវាអាចទាញយកទិន្នន័យណាមួយជាទម្រង់ XML ។ កាលនោះ អ្នកប្រើប្រាស់អាចរក្សាទិន្នន័យនៅក្រៅបណ្តាញបានច្រើន និងអាចយល់បានកាន់តែច្រើន ជាជាងនៅក្នុងពពកមួយចំនួន ហើយយើងបានផ្ដល់ឱ្យពួកគេ។ ការមិនផ្ទុកត្រូវបានចាប់ផ្តើមដោយការនាំចេញដោយដៃពីចំណុចប្រទាក់។ នោះគឺវាមិនទាន់អាចហៅថា API នៅឡើយទេ។

ក្នុងពេលជាមួយគ្នានេះ យើងបានចាប់ផ្តើមសហការជាមួយក្រុមហ៊ុន Rusagro - ពួកគេកំពុងប្រើប្រាស់ ERP "ចាស់ទុំ" រួចហើយសម្រាប់ការរៀបចំផែនការផលិតកម្ម និងការលក់ ប៉ុន្តែពួកគេបានដំណើរការដោយស្វ័យប្រវត្តិនូវការផ្ទុករទេះនៅរោងចក្រនៅក្នុង MyWarehouse ។ នេះជារបៀបដែលយើងទទួលបាន rudiments ដំបូងនៃ API ពិតប្រាកដមួយ៖ ការផ្លាស់ប្តូររវាងសេវាកម្មរបស់យើង និង ERP បានកើតឡើងដោយការផ្ញើឯកសារដ៏ធំមួយជាមួយនឹងទិន្នន័យលើឯកសារគ្រប់ប្រភេទ។

នេះគឺជាជម្រើសដ៏ល្អសម្រាប់ការផ្លាស់ប្តូរទិន្នន័យជាបាច់ ប៉ុន្តែរួមជាមួយនឹងឯកសារ ភាពអាស្រ័យរបស់ពួកគេត្រូវតែត្រូវបានផ្ទេរ៖ ព័ត៌មានអំពីទំនិញ អ្នកម៉ៅការ និងឃ្លាំង។ វាមិនមែនជាការលំបាកខ្លាំងណាស់ក្នុងការបង្កើតការចោលសំរាមបែបនេះក្នុងអំឡុងពេលនាំចេញ ប៉ុន្តែវាពិបាកក្នុងការតម្រៀបវាចេញក្នុងអំឡុងពេលនាំចូល ដោយសារព័ត៌មានទាំងអស់មកដល់ក្នុងកញ្ចប់តែមួយ៖ ទាំងឯកសារថ្មី និងអំពីឯកសារដែលមានស្រាប់។

XML API ដំបូងមិនមានរយៈពេលយូរទេ - បន្ទាប់ពីពីរឆ្នាំយើងបានចាប់ផ្តើមសាងសង់វាឡើងវិញ។ សូម្បីតែនៅពេលចាប់ផ្តើមការងាររបស់វា យើងបានធ្វើកំហុសជាច្រើនក្នុងការបង្កើតចំណុចប្រទាក់កម្មវិធី។

របៀបដែល XML API ត្រូវបានធ្វើឡើង៖ រូបភាពពីស្ថាបត្យកររបស់យើងម្នាក់។ ដោយវិធីនេះសូមរង់ចាំអត្ថបទរបស់គាត់។

នេះគឺជាកំហុសចម្បងរបស់យើង៖

1. ការសម្គាល់ JAXB ត្រូវបានសរសេរដោយផ្ទាល់ទៅសណ្តែកអង្គភាព។ ដើម្បីទំនាក់ទំនងជាមួយមូលដ្ឋានទិន្នន័យ យើងប្រើ Hibernate ហើយ JAXB markup ត្រូវបានបង្កើតឡើងសម្រាប់សណ្តែកដូចគ្នាទាំងនេះ។ កំហុសនេះបានលេចឡើងស្ទើរតែភ្លាមៗ៖ ការធ្វើបច្ចុប្បន្នភាពណាមួយចំពោះរចនាសម្ព័ន្ធទិន្នន័យតម្រូវឱ្យមានការជូនដំណឹងជាបន្ទាន់ដល់អ្នករាល់គ្នាដែលប្រើ API ឬការសាងសង់ការលួចចូលដែលនឹងធានាបាននូវភាពឆបគ្នាជាមួយនឹងរចនាសម្ព័ន្ធទិន្នន័យពីមុន។
2. API បានកើនឡើងជាកម្មវិធីបន្ថែម ហើយដំបូងឡើយយើងមិនបានកំណត់ថាតើវាជាផ្នែកណានៃផលិតផលនោះទេ។ យើងក៏មិនបានគិតពីថាតើ API គឺជាអ្វីដែលសំខាន់ ឬថាតើវាចាំបាច់ដើម្បីរក្សាភាពឆបគ្នាថយក្រោយសម្រាប់អតិថិជនដំបូងរបស់វា។ នៅចំណុចមួយ ចំនួនអ្នកប្រើប្រាស់ API មានប្រហែល 5% នៃចំនួនសរុបតិចតួច ហើយពួកគេត្រូវបានគេមិនអើពើ។ ការត្រងជាសកលដែលយើងបានធ្វើនៅពេលនោះបាននាំឱ្យយើងត្រូវបានគេប្រើជាផ្នែកខាងក្រោយ។ ការត្រងនេះមិនមែនជា GraphQL ទាល់តែសោះ ប៉ុន្តែអ្វីមួយដូចនោះ - វាដំណើរការតាមរយៈប៉ារ៉ាម៉ែត្រខ្សែអក្សរសំណួរជាច្រើន។ ជាមួយនឹងឧបករណ៍ដ៏មានអានុភាពបែបនេះ វាពិបាកសម្រាប់អ្នកប្រើប្រាស់ក្នុងការទប់ទល់ ហើយសំណើត្រូវបានផ្ទេរមកយើង ដូច្នេះពួកគេត្រូវបានផ្ញើដោយផ្ទាល់ពី UI នៃហាងអនឡាញរបស់ពួកគេ។ ស្ថានភាពនេះបានកើតឡើងជាការភ្ញាក់ផ្អើលមិនល្អមួយ ពីព្រោះការផ្តល់សេវាបែបនេះគួរតែទាមទារតម្លៃខុសៗគ្នា និងការយល់ដឹងផ្សេងគ្នាអំពី API ខ្លួនវាជាផលិតផលមួយ។
3. ដោយសារតែ API មិនត្រូវបានបង្កើតឡើងជាផលិតផលស្នូល ឯកសារ API ត្រូវបានផលិត និងបោះពុម្ពជាការគិតក្រោយ - តាមរយៈវិស្វកម្មបញ្ច្រាស។ ផ្លូវនេះហាក់ដូចជាសាមញ្ញ និងងាយស្រួលគ្រប់គ្រាន់ ប៉ុន្តែវាផ្ទុយនឹងការងារកិច្ចសន្យា។ នេះគឺជាពេលដែលមានសមាសធាតុជាក់លាក់មួយជាមួយនឹងគ្រោងការណ៍ប្រតិបត្តិការដែលបានដំឡើងជាមុន។ អ្នកអភិវឌ្ឍន៍អនុវត្តវាស្របតាមគ្រោងការណ៍ និងភារកិច្ចនេះ សមាសធាតុត្រូវបានសាកល្បង អតិថិជនទទួលបានផលិតផលដែលត្រូវនឹងគំនិតរបស់អ្នកវិភាគ។ វិស្វកម្មបញ្ច្រាសបោះផលិតផលមួយទៅកាន់ទីផ្សារដែលមានស្រាប់៖ ជាមួយនឹងឈើច្រត់ ដំណោះស្រាយចម្លែក និងកង់ជំនួសឱ្យមុខងារចាំបាច់។
4. លំហូរទាំងមូលនៃសំណើដែលបានមកតាមរយៈ API អាចត្រូវបានវិភាគថាគ្មានអ្វីក្រៅពី Nginx ឬកំណត់ហេតុម៉ាស៊ីនមេកម្មវិធីនោះទេ។ នេះមិនអនុញ្ញាតឱ្យយើងកំណត់អត្តសញ្ញាណប្រធានបទ លើកលែងតែអ្នកប្រើប្រាស់ និងអ្នកជាវ។ ប្រសិនបើមិនមានវិធីដើម្បីគ្រប់គ្រងការចុះឈ្មោះកម្មវិធី ឬអតិថិជនទេនោះ វាមិនអាចវិភាគស្ថានភាពបានទេ។ បញ្ហានេះមានផលប៉ះពាល់តិចតួចបំផុតលើការអភិវឌ្ឍន៍ API វាគឺអំពីការយល់ដឹងអំពីភាពពាក់ព័ន្ធ និងមុខងាររបស់វា។

ការព្យាយាមលេខពីរ៖ REST API

ក្នុងឆ្នាំ 2010 យើងបានព្យាយាមបង្កើតប្រព័ន្ធប្តូរប្រាក់ជាមួយនឹងគណនេយ្យអនឡាញ - BukhSoft ។ វាមិនបានហោះចេញទេ។ ទោះយ៉ាងណាក៏ដោយ ក្នុងអំឡុងពេលដំណើរការសមាហរណកម្ម API ពេញលេញបានបង្ហាញខ្លួន៖ សេវាប្តូរប្រាក់ REST ដែលមិនមានសេរីភាពដូចជាការចូលប្រើប្រតិបត្តិការក្នុងទម្រង់នៃការហៅ RPC ជាដើម។ ការប្រាស្រ័យទាក់ទងទាំងអស់ជាមួយ API ត្រូវបាននាំយកទៅរបៀបស្តង់ដារសម្រាប់ការសម្រាក៖ ខ្សែអក្សរសំណួរមានឈ្មោះរបស់អង្គភាព ហើយប្រតិបត្តិការដែលបានអនុវត្តជាមួយវាត្រូវបានបញ្ជាក់ដោយប្រើវិធីសាស្ត្រ http ។ យើង​បាន​បន្ថែម​ការ​ត្រង​នៅ​ពេល​នៃ​ការ​អាប់ដេត​អង្គភាព ហើយ​ឥឡូវ​នេះ​អ្នក​ប្រើ​មាន​លទ្ធភាព​បង្កើត​ការ​ចម្លង​ជាមួយ​នឹង​ប្រព័ន្ធ​របស់​ពួកគេ​។

ក្នុងឆ្នាំដដែលនោះ API សម្រាប់ការដកទំនិញចេញពីឃ្លាំង និងសមតុល្យផលិតផលបានបង្ហាញខ្លួន។ ផ្នែកដ៏មានតម្លៃបំផុតនៃប្រព័ន្ធ ដូចជាការផ្លាស់ប្តូរឯកសារបឋម និងទិន្នន័យដែលបានគណនាលើសមតុល្យ និងថ្លៃដើមទំនិញ បានក្លាយជាមានសម្រាប់អ្នកប្រើប្រាស់តាមរយៈ API ។

នៅខែធ្នូ ឆ្នាំ 2015 ក្រុមហ៊ុន RetailCRM បានបោះពុម្ពបណ្ណាល័យភាគីទីបីដំបូងសម្រាប់ការចូលប្រើ API របស់យើង។ វាបានចាប់ផ្តើមប្រើប្រាស់យ៉ាងសកម្ម ខណៈពេលដែលប្រជាប្រិយភាពនៃសេវាកម្មទាំងមូលកើនឡើង ការផ្ទុកនៅលើ API បានកើនឡើងលឿនជាងការផ្ទុកនៅលើចំណុចប្រទាក់គេហទំព័រ។ ថ្ងៃមួយ កំណើនបានប្រែទៅជាការកើនឡើងបន្ទុក។

ហើយការលោតនេះ បង្ហាញដោយព្រួញនៅខាងឆ្វេង ធ្វើឱ្យម៉ាស៊ីនមេដែលបម្រើ API របស់យើងភ្ញាក់ផ្អើលទាំងស្រុង។ អស់រយៈពេលមួយសប្តាហ៍ យើងបានស្វែងយល់ថា តើអ្វីជាការបង្កើតបន្ទុកនេះ។ វាបានប្រែក្លាយថាទាំងនេះគឺជាសំណើដូចគ្នាដែលបានបញ្ជូនទៅ API របស់យើងពីការបញ្ចប់ផ្នែកខាងមុខរបស់អតិថិជន។ អតិថិជនប្រហែល 50 នាក់បានញ៉ាំអ្វីគ្រប់យ៉ាង។ ពេល​នោះ​ហើយ​ដែល​យើង​បាន​ដឹង​ពី​កំហុស​មួយ​របស់​យើង គឺ​ការ​ខ្វះ​ដែន​កំណត់​ទាំង​ស្រុង។

ជាលទ្ធផល យើងបានដាក់កម្រិតលើចំនួនសំណើក្នុងពេលដំណាលគ្នា។ ឥឡូវនេះវាអាចទៅរួចក្នុងការបើកសំណើមិនលើសពីពីរក្នុងពេលតែមួយពីគណនីមួយ។ នេះគឺគ្រប់គ្រាន់ដើម្បីដំណើរការក្នុងរបៀបចម្លងសម្រាប់ការផ្លាស់ប្តូរទិន្នន័យជាបាច់។ ហើយអ្នកដែលចង់ប្រើពួកយើងជា backend ត្រូវបានបង្ខំឱ្យគោរពតាមពន្ធបន្ថែមចាប់ពីពេលនោះមក ចាប់តាំងពីពួកគេបានណែនាំការងារលើគណនីច្រើនទៅក្នុងកម្មវិធីរបស់ពួកគេ។

ចូរយើងទទួលបានវាតាមលំដាប់

ចាប់តាំងពីឆ្នាំ 2014 តំរូវការ API ដែលមានស្រាប់បានក្លាយជាផ្នែកសំខាន់នៃអាជីវកម្ម ហើយ API ខ្លួនវាបានបង្កើតបរិមាណទិន្នន័យដ៏ធំបំផុតក្នុងការផ្លាស់ប្តូរទិន្នន័យជាមួយអតិថិជន។ នៅឆ្នាំ 2015 យើងបានចាប់ផ្តើមគម្រោងមួយដើម្បីសម្អាត API ។ យើងបានជ្រើសរើស JSON ជាទម្រង់ជំនួសឱ្យ XML ហើយចាប់ផ្តើមបង្កើតវាដោយផ្អែកលើលក្ខណៈពិសេសដែលត្រូវបានកំណត់អត្តសញ្ញាណកំឡុងពេលអនុវត្តកំណែមុន៖

1. លទ្ធភាពក្នុងការគ្រប់គ្រងកំណែ។ កំណែប្រែអនុញ្ញាតឱ្យអ្នកអភិវឌ្ឍកំណែថ្មីដោយមិនប៉ះពាល់ដល់កម្មវិធីដែលមានស្រាប់ ឬរំខានដល់បទពិសោធន៍អ្នកប្រើប្រាស់។
2. សមត្ថភាពសម្រាប់អ្នកប្រើប្រាស់ដើម្បីមើលទិន្នន័យមេតានៅក្នុងការឆ្លើយតបដោយខ្លួនឯងដែលពួកគេទទួលបាន។
3. លទ្ធភាពនៃការផ្លាស់ប្តូរឯកសារធំ ៗ ។ ប្រសិនបើយើងដំណើរការឯកសារដែលមានមុខតំណែងច្រើនជាង 4-5 ពាន់ នោះវាក្លាយជាបញ្ហាសម្រាប់ម៉ាស៊ីនមេ៖ ប្រតិបត្តិការវែង សំណើ http វែង។ យើងបានបង្កើតយន្តការពិសេសមួយដែលអនុញ្ញាតឱ្យធ្វើបច្ចុប្បន្នភាពឯកសារជាផ្នែកៗ និងគ្រប់គ្រងមុខតំណែងនីមួយៗនៃឯកសារនេះដោយបញ្ជូនពួកវាទៅម៉ាស៊ីនមេ។
4. ឧបករណ៍ចម្លងក៏មាននៅក្នុងកំណែមុនដែរ។
5. ដែនកំណត់ផ្ទុកគឺដូចជាកេរ្តិ៍ដំណែលនៃតុងរួចដែលត្រូវបានបោះជំហាននៅក្នុងកំណែមុន។ យើងបានណែនាំដែនកំណត់លើចំនួនសំណើក្នុងរយៈពេលមួយ ចំនួននៃសំណើស្របគ្នា និងសំណើពីអាសយដ្ឋាន IP មួយ។

ចាប់តាំងពីពេលនោះមក យើងបានចេញផ្សាយកំណែអនីតិជនចំនួនពីរនៃ API និងបានបើកដំណើរការ APIs ឯកទេសជាច្រើន ប៉ុន្តែវិធីសាស្រ្តទាំងមូលនៅតែដដែល។ ទម្រង់ផ្លាស់ប្តូរដែលបានធ្វើបច្ចុប្បន្នភាព និងស្ថាបត្យកម្មថ្មីបានធ្វើឱ្យវាអាចជួសជុលកង្វះ API បានលឿនជាងមុន។

MyWarehouse API ថ្ងៃនេះ

ថ្ងៃនេះ MyWarehouse API ដោះស្រាយបញ្ហាជាច្រើន៖

• ការផ្លាស់ប្តូរទិន្នន័យជាមួយហាងអនឡាញ ប្រព័ន្ធគណនេយ្យ ធនាគារ;
• ការទទួលបានទិន្នន័យការគណនា, របាយការណ៍;
• ប្រើជាផ្នែកខាងក្រោយសម្រាប់កម្មវិធីអតិថិជន - កម្មវិធីទូរស័ព្ទរបស់យើង និងការចុះឈ្មោះសាច់ប្រាក់លើតុធ្វើការតាមរយៈ API
• ការផ្ញើការជូនដំណឹងអំពីការផ្លាស់ប្តូរទិន្នន័យនៅក្នុង MyWarehouse — webhooks;
• ទូរស័ព្ទ;
• ប្រព័ន្ធភក្ដីភាព។

ផ្អែកលើ API នាយកប្រតិបត្តិរបស់យើងគឺ Askar Rakhimberdiev រមាស ក្នុងរយៈពេល 4 ម៉ោងខ្ញុំបានសរសេរ Telegram bot ដែលទាញសមតុល្យតាមរយៈ API៖ github.com/arahimberdiev/com-lognex-telegram-moysklad-stock

ឥឡូវនេះលេខស្ងួត។

នេះគឺជាស្ថិតិរបស់យើងសម្រាប់ REST API ចាស់៖

• 400 ក្រុមហ៊ុន;
• អ្នកប្រើប្រាស់ 600;
• 2 លានសំណើក្នុងមួយថ្ងៃ;
• 200 GB / ថ្ងៃនៃចរាចរណ៍ចេញ។

ហើយនេះគឺជាអ្វីដែលយើងបានមកសម្រាប់ MyWarehouse APIs ទាំងអស់៖

• ការរួមបញ្ចូលច្រើនជាង 70 (ពួកវាខ្លះអាចមើលបាននៅទីនេះ www.moysklad.ru/integratsii);
• 8500 ក្រុមហ៊ុន;
• អ្នកប្រើប្រាស់ 12;
• 46 លានសំណើក្នុងមួយថ្ងៃ;
• 2 Tb / ថ្ងៃនៃចរាចរណ៍ចេញ។

មាន​អ្វី​បន្ទាប់

ផែនការសម្រាប់ការអភិវឌ្ឍន៍ API គឺស្ថិតនៅក្រោមការពិភាក្សាយ៉ាងសកម្ម។ យើងព្យាយាមពិចារណាលើបទពិសោធន៍ប្រតិបត្តិការដែលអ្នកប្រើប្រាស់ផ្តល់ឱ្យយើង។ វាមិនតែងតែអាចធ្វើអ្វីគ្រប់យ៉ាងក្នុងពេលតែមួយបាននោះទេ ប៉ុន្តែកំណែថ្មីនៃ API ដែលមានទិន្នន័យមេតាងាយស្រួលជាង និងរចនាសម្ព័ន្ធដែលមិនសូវធំទូលាយ OAuth សម្រាប់ការផ្ទៀងផ្ទាត់ និង API សម្រាប់កម្មវិធីបង្កប់នៅក្នុងចំណុចប្រទាក់គឺនៅជិតជ្រុង។

អ្នកអាចតាមដានព័ត៌មាននៅលើគេហទំព័រពិសេសសម្រាប់អ្នកអភិវឌ្ឍន៍នៃការរួមបញ្ចូលជាមួយ MyWarehouse៖ dev.moysklad.ru.

ប្រភព: www.habr.com