واجهة برمجة تطبيقات مكتوبة - XML ​​مكسور (اثنان)

ظهر أول تطبيق MyStore API قبل 10 سنوات. نعمل طوال الوقت على الإصدارات الحالية من واجهة برمجة التطبيقات (API) وتطوير إصدارات جديدة. وقد تم بالفعل دفن العديد من إصدارات API.

ستحتوي هذه المقالة على الكثير من الأشياء: كيفية إنشاء واجهة برمجة التطبيقات ، ولماذا تحتاج الخدمة السحابية إليها ، وما يمنح المستخدمين ما أشعل النار الذي تمكنا من المضي قدمًا فيه وما نريد القيام به بعد ذلك.

اسمي Oleg Alekseev oalexeev ، أنا المدير التقني والمؤسس المشارك لـ MySklad.

لماذا جعل API لخدمة

يستخدم عملاؤنا ، الذين يمثلون عشرات الآلاف من رواد الأعمال ، الحلول السحابية: البنوك ، المتاجر الإلكترونية ، محاسبة المنتجات ، CRM. متصل بواحد - ومن الصعب إيقافه بالفعل. والآن الخدمة الخامسة والثامنة والعاشرة تجعل مهمة صاحب المشروع أسهل ، لكن المستخدمين ينقلون البيانات بين هذه الخدمات السحابية يدويًا. يتحول العمل إلى كابوس.

الحل الواضح هو منح المستخدمين القدرة على نقل البيانات بين الخدمات السحابية. على سبيل المثال ، قم باستيراد وتصدير البيانات كملفات ، والتي يمكن بعد ذلك تنزيلها إلى الخدمة المطلوبة. عادة ما يتم تغيير الملفات إلى تنسيق كل خدمة. هذا عمل يدوي بسيط إلى حد ما ، ولكن مع زيادة عدد هذه الخدمات ، يصبح أداء هذه الخدمة أكثر صعوبة.

لذلك ، فإن الخطوة التالية هي API. مع ذلك ، تستفيد الخدمة السحابية من توصيل خدمات متعددة في نقطة واحدة. ظهور مثل هذا النظام البيئي يجذب عملاء جدد بسبب فرص إضافية. منتج ذو وظائف جديدة يصبح أكثر ربحية ومفيدة.

إذا قمت بإنشاء واجهات البرنامج الخاصة بك ، فإنه يجذب البائعين الخارجيين في شكل المبرمجين الذين يعرفون عن المنتج الخاص بك بفضل API. يبدأون في بناء حلول تستند إلى واجهة برمجة التطبيقات المقترحة وكسب المال عن طريق أتمتة مهام عملائهم.

نظام المحاسبة في MyStore مبني على عمليات بسيطة. الشيء الرئيسي هو العمل مع المستندات الأساسية ، والقدرة على قبول وشحن البضائع ، وتلقي تقارير العمل على أساس الأساسي. هناك أيضا نقل البيانات ، على سبيل المثال ، إلى المحاسبة السحابية ، وإيصالها من النظم المصرفية أو منافذ البيع بالتجزئة. نعمل أيضًا مع المتاجر عبر الإنترنت: نتلقى معلومات حول البضائع ونرسل بيانات عن الأرصدة.

أول MyStore API

على مدار أكثر من 10 سنوات من عمل MyStore مع واجهة برمجة التطبيقات (API) ، حصلنا على جميع أنواع الدمج التي تسمح لك بتبادل البيانات والعمل مع البنوك وإجراء المدفوعات واستخدام الاتصالات الهاتفية الخارجية.

في السنة الأولى ، سمحنا بتحميل أي بيانات بتنسيق XML. ثم كان أكثر وضوحًا ومألوفًا للمستخدمين الاحتفاظ بالبيانات في وضع عدم الاتصال ، وليس في نوع من السحابة هناك ، وقد قدمنا ​​لهم ذلك. تم بدء التنزيل عن طريق التصدير اليدوي من الواجهة. وهذا يعني أنه لا يمكن استدعاء API بعد.

ثم بدأنا في التعاون مع Rusagro - لقد استخدموا بالفعل ERP "للبالغين" لتخطيط الإنتاج والمبيعات ، ولكن تم تحميل السيارات في المصانع في MySklad. لذلك حصلنا على أول أساسيات لواجهة برمجة التطبيقات هذه: تم التبادل بين خدمتنا و ERP عن طريق إرسال ملف كبير به بيانات لجميع أنواع المستندات.

يعد هذا خيارًا جيدًا لتبادل دفعات البيانات ، ولكن إلى جانب المستندات ، كان من الضروري نقل تبعياتها: معلومات عن البضائع والمقاولين والمستودعات. ليس من الصعب إنشاء مثل هذا الطمر أثناء التصدير ، ولكن يصعب تفكيكه أثناء الاستيراد ، حيث أن جميع المعلومات تأتي في حزمة واحدة: سواء عن الوثائق الجديدة أو حول المستندات الموجودة.

لم تستمر واجهة برمجة تطبيقات XML الأولى لفترة طويلة - بعد عامين ، بدأنا في إعادة بنائها. حتى في بداية عمله ، ارتكبنا العديد من الأخطاء عند بناء واجهة البرنامج.


كيفية عمل واجهة برمجة تطبيقات XML: رسم توضيحي من أحد المهندسين المعماريين لدينا. بالمناسبة ، انتظر مقالاته.

وهنا أخطائنا الرئيسية:

1. تم ترميز JAXB مباشرة على حبوب الكيان. نحن نستخدم السبات للتواصل مع قاعدة البيانات ، وتم وضع علامات JAXB على نفس البقوليات. ظهر هذا الخطأ على الفور تقريبًا: أي تحديث لبنية البيانات أدى إلى الحاجة إلى إخطار أي شخص يستخدم واجهة برمجة التطبيقات على وجه السرعة ، أو لإنشاء عكازات من شأنها أن تضمن التوافق مع بنية البيانات السابقة.
2. نمت واجهة برمجة التطبيقات كنوع من الإضافة ، وفي البداية لم نحدد أي جزء من المنتج يتكون. لم نفكر فيما إذا كانت واجهة برمجة التطبيقات شيءًا مهمًا أم لا ، ما إذا كان من الضروري الحفاظ على التوافق مع العملاء الأولين. في مرحلة ما ، كان عدد مستخدمي واجهة برمجة التطبيقات (API) حوالي 5٪ من إجمالي العدد الصغير ، ولم يتم توجيه أي اهتمام لهم. التصفية العالمية التي تم إجراؤها في الوقت المناسب أدت بنا إلى أن نستخدم كخلفية. هذا التصفية لم يكن GraphQL على الإطلاق ، ولكنه شيء من هذا القبيل - لقد نجح في الكثير من معلمات سلسلة الاستعلام. باستخدام هذه الأداة القوية ، كان من الصعب على المستخدمين المقاومة ، وتم نقل الطلبات إلينا حتى يتم إرسالها مباشرة من واجهة المستخدم الخاصة بمتاجرهم عبر الإنترنت. كان الموقف مفاجأة غير سارة ، لأن توفير مثل هذه الخدمة يجب أن يتطلب رسومًا مختلفة وفهمًا مختلفًا لواجهة برمجة التطبيقات نفسها كمنتج.
3. نظرًا لحقيقة أن واجهة برمجة التطبيقات لم تتطور كمنتج رئيسي ، فقد تم إنتاج وثائق واجهة برمجة التطبيقات ونشرها وفقًا للمبدأ المتبقي - من خلال الهندسة العكسية. بهذه الطريقة تبدو بسيطة ومريحة للغاية ، ولكن على عكس العمل العقد. هذا عندما يكون هناك مكون معين مع خطة عمل محددة مسبقا. يقوم المطور بتنفيذها وفقًا لهذا المخطط والمهمة ، ويتم اختبار المكون ، ويتلقى العميل منتجًا يطابق فكرة المحلل. الهندسة العكسية ، من ناحية أخرى ، تقوم بإلقاء منتج موجود ببساطة: مع العكازات والحلول الغريبة والدراجات بدلاً من الوظيفة الضرورية.
4. لا يمكن تحليل مجرى الطلبات بالكامل الذي جاء عبر واجهة برمجة التطبيقات أكثر من سجل Nginx أو خادم تطبيقات. هذا لم يسمح لنا بعزل مجالات المواضيع ، باستثناء ربما تقسيمها على المستخدمين والمشتركين. إذا لم يكن من الممكن تنظيم تسجيل التطبيق أو العملاء ، يصبح من المستحيل تحليل الموقف. كان لهذه المشكلة أقل تأثير على تطوير واجهة برمجة التطبيقات ؛ فهي تتعلق بفهم أهميتها ووظيفتها.

محاولة رقم اثنين: REST API

في عام 2010 ، حاولنا إنشاء نظام تبادل مع المحاسبة عبر الإنترنت - BukhSoft. لم تقلع ولكن في عملية التكامل ، ظهرت واجهة برمجة تطبيقات كاملة: خدمة تبادل REST ، حيث لم تكن هناك حريات مثل استدعاءات العمليات في شكل مكالمات RPC. تم إحضار جميع الاتصالات بـ API إلى الوضع القياسي للراحة: تحتوي سلسلة الاستعلام على اسم الكيان ، ويتم تعيين العملية التي يتم تنفيذها باستخدام طريقة http-. لقد أضفنا التصفية في وقت تحديث الكيانات ، وأصبح لدى المستخدمين الآن الفرصة لإنشاء نسخ متماثلة مع أنظمتهم.

في نفس العام ، ظهر واجهة برمجة التطبيقات لتفريغ المخازن وأرصدة السلع. أصبحت الأجزاء الأكثر قيمة في النظام متاحة للمستخدمين من خلال واجهة برمجة التطبيقات - تبادل الوثائق الأولية والبيانات المقدرة حول أرصدة وتكلفة البضائع.

في ديسمبر 2015 ، نشرت RetailCRM أول مكتبة تابعة لجهة خارجية للوصول إلى واجهة برمجة التطبيقات. لقد بدأوا في استخدامها بفعالية كبيرة ، بينما ازدادت شعبية الخدمة ككل ، زاد الحمل على واجهة برمجة التطبيقات بشكل أسرع من التحميل على واجهة الويب. مرة واحدة ، تحول النمو إلى قفزة في الحمل.





وأدت هذه القفزة ، التي يظهرها السهم على اليسار ، إلى دهشة تامة للخادم الذي يخدم API الخاصة بنا. لمدة أسبوع ، أدركنا بالضبط ما يولده هذا الحمل. لقد تبين أن هذه هي الطلبات التي يتم بثها إلى واجهة برمجة التطبيقات من جبهات العملاء. حوالي 50 من العملاء أكلوا كل شيء. عندها أدركنا أحد أخطائنا - الغياب التام للحدود.

نتيجة لذلك ، قدمنا ​​حدًا لعدد الطلبات المتزامنة. من حساب واحد ، أصبح من الممكن فتح ما لا يزيد عن طلبين في وقت واحد. هذا يكفي للعمل في وضع النسخ المتماثل لتبادل البيانات في وضع الدُفعات. وأولئك الذين أرادوا أن يستخدمونا كخلفية ، منذ تلك اللحظة أجبروا على الامتثال أكثر للتعريفات ، لأنها أدخلت العمل على عدة حسابات في برامجهم.

مرتب

منذ عام 2014 ، أصبح الطلب على واجهة برمجة التطبيقات الحالية جزءًا مهمًا من النشاط التجاري ، كما أن واجهة برمجة التطبيقات (API) نفسها قد أنتجت أكبر كمية من البيانات في تبادل البيانات مع العملاء. في عام 2015 ، أطلقنا مشروعًا لتنظيف واجهة برمجة التطبيقات. لقد اخترنا JSON بدلاً من XML كتنسيق وبدأنا في بنائه على أساس الميزات التي تم الكشف عنها أثناء تنفيذ الإصدار السابق:

1. القدرة على إدارة الإصدارات. يتيح لك الإصدار تعيين إصدار جديد دون التأثير على تطبيق موجود ودون تعطيل المستخدمين.
2. قدرة المستخدم على رؤية البيانات الوصفية في الاستجابة التي يتلقاها.
3. القدرة على تبادل الوثائق الكبيرة. إذا قمنا بمعالجة مستند يحتوي على عدد من المواضع أكثر من 4-5 آلاف ، فسيصبح ذلك مشكلة بالنسبة للخادم: معاملة طويلة ، طلب http طويل. لقد أنشأنا آلية خاصة تتيح لك تحديث المستند في أجزاء وإدارة المواقف الفردية لهذا المستند عن طريق إرسالها إلى الخادم.
4. أدوات للنسخ المتماثل - كانت في الإصدار السابق.
5. تشبه حدود التحميل إرث الخليع الذي تم تدوينه في الإصدار السابق. فرض قيود على عدد الطلبات في فترة زمنية ، وعدد الطلبات المتزامنة والطلبات من عنوان IP واحد.

منذ تلك اللحظة ، قمنا بإصدار نسختين صغيرتين من واجهة برمجة التطبيقات وأطلقنا عدة واجهات برمجة تطبيقات متخصصة ، ولكن بشكل عام ظل النهج على حاله. أتاح تنسيق التبادل المحدث والبنية الجديدة تصحيح أوجه القصور في واجهة برمجة التطبيقات بشكل أسرع.

MyStore API اليوم

تعمل واجهة MyStore API اليوم على حل العديد من المشكلات:

• تبادل البيانات مع المخازن على الإنترنت ، أنظمة المحاسبة ، البنوك.
• تلقي بيانات التسوية والتقارير.
• استخدم كخلفية لتطبيقات العملاء - تعمل تطبيقات الهاتف المحمول ومكتب سطح المكتب النقدي من خلال واجهة برمجة التطبيقات
• إرسال إشعارات حول تغييرات البيانات في MyStore - webhooks ؛
• الاتصالات الهاتفية.
• نظم الولاء.

استنادًا إلى واجهة برمجة التطبيقات (API) ، كتب الرئيس التنفيذي لدينا عسكر رخيمبرديف رهينو في أربع ساعات روبوت برقية يقوم بسحب الباقي عبر واجهة برمجة التطبيقات: github.com/arahimberdiev/com-lognex-telegram-moysklad-stock

الآن أرقام جافة.

فيما يلي إحصائياتنا عن واجهة برمجة تطبيقات REST القديمة:

• 400 شركة
• 600 مستخدم
• 2 مليون طلب في اليوم ؛
• 200 جيجابايت / يوم من حركة المرور الصادرة.

وهنا ما توصلنا إليه مع كل واجهة برمجة تطبيقات MyStore:

• أكثر من 70 تكاملًا (يمكن العثور على بعضها هنا www.moysklad.ru/integratsii ) ؛
• 8500 شركة
• 12000 مستخدم ؛
• 46 مليون طلب يوميًا ؛
• 2 تيرابايت / يوم من حركة المرور الصادرة.

ما التالي

خطط تطوير API قيد المناقشة النشطة. نحاول أن نأخذ في الاعتبار تجربة التشغيل التي يزودنا بها المستخدمون. ليس دائمًا وليس كل شيء يتم تنفيذه على الفور ، ولكن ليس بعيدًا هو إصدار جديد من واجهة برمجة التطبيقات (API) مع بيانات تعريف أكثر ملاءمة وبنية أقل أهمية ، OAuth للمصادقة ، وواجهة برمجة التطبيقات للتطبيقات المدمجة في الواجهة.

يمكنك متابعة الأخبار على موقع خاص لمطوري التكامل مع MySklad: dev.moysklad.ru .