একটি API লিখেছেন - XML ​​(দুই) ছিঁড়ে গেছে

প্রথম MyWarehouse API ১০ বছর আগে আবির্ভূত হয়েছিল। এই পুরো সময় ধরে আমরা API-এর বিদ্যমান সংস্করণগুলি নিয়ে কাজ করছি এবং নতুনগুলি তৈরি করছি। এবং API এর বেশ কয়েকটি সংস্করণ ইতিমধ্যেই সমাহিত করা হয়েছে।

এই প্রবন্ধে অনেক কিছু আলোচনা করা হবে: API কীভাবে তৈরি করা হয়েছিল, কেন একটি ক্লাউড পরিষেবার প্রয়োজন হয়, এটি ব্যবহারকারীদের কী দেয়, আমরা কী ভুল করেছি এবং আমরা পরবর্তীতে কী করতে চাই।

আমার নাম ওলেগ আলেকসিভ। ওলেক্সিভ, আমি মাইওয়্যারহাউসের টেকনিক্যাল ডিরেক্টর এবং সহ-প্রতিষ্ঠাতা।

কেন একটি পরিষেবার জন্য একটি API তৈরি করবেন?

আমাদের ক্লায়েন্টরা, যাদের মধ্যে কয়েক হাজার উদ্যোক্তা রয়েছেন, সক্রিয়ভাবে ক্লাউড সমাধান ব্যবহার করেন: ব্যাংকিং, অনলাইন স্টোর, ইনভেন্টরি নিয়ন্ত্রণ, সিআরএম। একটির সাথে সংযোগ স্থাপন করুন এবং এটি থামানো কঠিন। আর এখন পঞ্চম, অষ্টম, দশম পরিষেবা উদ্যোক্তার কাজকে সহজ করে তোলে, কিন্তু ব্যবহারকারীরা এই ক্লাউড পরিষেবাগুলির মধ্যে ম্যানুয়ালি ডেটা স্থানান্তর করে। কাজ ক্রমশ দুঃস্বপ্নে পরিণত হচ্ছে।

এর সুস্পষ্ট সমাধান হলো ব্যবহারকারীদের ক্লাউড পরিষেবাগুলির মধ্যে ডেটা স্থানান্তর করার ক্ষমতা প্রদান করা। উদাহরণস্বরূপ, ফাইল হিসেবে ডেটা আমদানি এবং রপ্তানি করা, যা পরে পছন্দসই পরিষেবায় আপলোড করা যেতে পারে। প্রতিটি পরিষেবার ফর্ম্যাট অনুসারে ফাইলগুলি সাধারণত পরিবর্তন করা হয়। এটি কমবেশি সহজ ম্যানুয়াল কাজ, কিন্তু এই পরিষেবাগুলির সংখ্যা বাড়ার সাথে সাথে এটি করা আরও কঠিন হয়ে ওঠে।

তাহলে পরবর্তী ধাপ হল API। এর মাধ্যমে, ক্লাউড পরিষেবা এক জায়গায় একাধিক পরিষেবা সংযুক্ত করার সুবিধা পায়। এই ধরনের একটি বাস্তুতন্ত্রের উত্থান অতিরিক্ত সুযোগের কারণে নতুন ক্লায়েন্টদের আকর্ষণ করে। নতুন কার্যকারিতা সহ পণ্যটি আরও লাভজনক এবং কার্যকর হয়ে ওঠে।

আপনার নিজস্ব API তৈরি করলে প্রোগ্রামারদের আকারে তৃতীয় পক্ষের বিক্রেতারা আকৃষ্ট হন যারা API এর মাধ্যমে আপনার পণ্য সম্পর্কে জানেন। তারা প্রস্তাবিত API-এর উপর ভিত্তি করে সমাধান তৈরি শুরু করে এবং তাদের গ্রাহকদের কাজ স্বয়ংক্রিয় করে অর্থ উপার্জন করে।

মাইওয়্যারহাউসের হিসাব ব্যবস্থা সহজ প্রক্রিয়ার উপর ভিত্তি করে তৈরি। মূল বিষয় হল প্রাথমিক নথি নিয়ে কাজ করা, পণ্য গ্রহণ ও পাঠানোর ক্ষমতা এবং প্রাথমিক নথির উপর ভিত্তি করে ব্যবসার জন্য প্রতিবেদন গ্রহণ করা। উদাহরণস্বরূপ, ক্লাউড অ্যাকাউন্টিংয়ে ডেটা স্থানান্তর এবং ব্যাংকিং সিস্টেম বা খুচরা আউটলেট থেকে এর প্রাপ্তিও রয়েছে। আমরা অনলাইন স্টোরগুলির সাথেও কাজ করি: আমরা পণ্য সম্পর্কে তথ্য পাই এবং ব্যালেন্স সম্পর্কে ডেটা পাঠাই।

মাইওয়্যারহাউসের প্রথম এপিআই

API-এর সাথে MyWarehouse-এর ১০ বছরের কাজের মাধ্যমে, আমরা সকল ধরণের ইন্টিগ্রেশন অর্জন করেছি যা আমাদের ডেটা বিনিময় করতে, ব্যাংকের সাথে কাজ করতে, অর্থপ্রদান করতে এবং বহিরাগত টেলিফোনি ব্যবহার করতে দেয়।

প্রথম বছরে, আমরা XML ফর্ম্যাটে যেকোনো ডেটা ডাউনলোড করা সম্ভব করেছিলাম। সেই সময়, ব্যবহারকারীদের কাছে ডেটা অফলাইনে রাখা অনেক বেশি বোধগম্য এবং পরিচিত ছিল, কোনও ক্লাউডের পরিবর্তে, এবং আমরা তাদের এটি দিয়েছিলাম। ইন্টারফেস থেকে ম্যানুয়াল এক্সপোর্টের মাধ্যমে আনলোডিং শুরু হয়েছিল। অর্থাৎ, এটিকে এখনও API বলা যায়নি।

একই সময়ে, আমরা রুসাগ্রো কোম্পানির সাথে সহযোগিতা শুরু করি - তারা ইতিমধ্যেই উৎপাদন এবং বিক্রয় পরিকল্পনার জন্য একটি "পরিপক্ক" ERP ব্যবহার করছিল, কিন্তু তারা মাইওয়্যারহাউসের কারখানাগুলিতে ওয়াগন লোডিং স্বয়ংক্রিয়ভাবে সম্পন্ন করেছিল। এইভাবেই আমরা একটি বাস্তব API-এর প্রথম মৌলিক বিষয়গুলি পেলাম: আমাদের পরিষেবা এবং ERP-এর মধ্যে বিনিময় ঘটেছিল সকল ধরণের নথির ডেটা সহ একটি বড় ফাইল পাঠানোর মাধ্যমে।

ব্যাচ ডেটা বিনিময়ের জন্য এটি একটি ভালো বিকল্প, তবে নথির সাথে সাথে, তাদের নির্ভরতাগুলিও স্থানান্তর করতে হয়েছিল: পণ্য, ঠিকাদার এবং গুদাম সম্পর্কে তথ্য। রপ্তানির সময় এই ধরনের ডাম্প তৈরি করা এত কঠিন নয়, তবে আমদানির সময় এটি বাছাই করা বেশ কঠিন, কারণ সমস্ত তথ্য একটি প্যাকেজে আসে: নতুন এবং বিদ্যমান নথি উভয় সম্পর্কেই।

প্রথম XML API বেশিদিন টিকেনি - দুই বছর পর আমরা এটি পুনর্নির্মাণ শুরু করি। এমনকি এর কাজের শুরুতে, আমরা সফ্টওয়্যার ইন্টারফেস তৈরিতে বেশ কিছু ভুল করেছিলাম।

XML API কীভাবে তৈরি করা হয়েছিল: আমাদের একজন স্থপতির চিত্র। যাই হোক, তার লেখাগুলোর জন্য অপেক্ষা করুন।

আমাদের প্রধান ভুলগুলি এখানে:

1. JAXB মার্কআপ সরাসরি সত্তা বিনসে লেখা হয়েছিল। ডাটাবেসের সাথে যোগাযোগের জন্য আমরা হাইবারনেট ব্যবহার করি, এবং এই একই বিনগুলির জন্য JAXB মার্কআপ তৈরি করা হয়েছিল। এই ত্রুটিটি প্রায় তাৎক্ষণিকভাবে দেখা দেয়: ডেটা স্ট্রাকচারের যেকোনো আপডেটের জন্য API ব্যবহারকারী সকলকে জরুরিভাবে অবহিত করতে হয়, অথবা এমন হ্যাক তৈরি করতে হয় যা পূর্ববর্তী ডেটা স্ট্রাকচারের সাথে সামঞ্জস্যপূর্ণ হবে।
2. API একটি অ্যাড-অন হিসেবে বিকশিত হয়েছিল, এবং আমরা প্রাথমিকভাবে এটি পণ্যের কোন অংশ তা সংজ্ঞায়িত করিনি। আমরা এও ভাবিনি যে API কি গুরুত্বপূর্ণ কিছু ছিল, নাকি এর প্রথম ক্লায়েন্টদের জন্য ব্যাকওয়ার্ড সামঞ্জস্য বজায় রাখা প্রয়োজন ছিল। এক পর্যায়ে, API ব্যবহারকারীর সংখ্যা মোট ব্যবহারকারীর প্রায় ৫% ছিল, এবং তাদের উপেক্ষা করা হয়েছিল। সেই সময়ে আমরা যে সার্বজনীন ফিল্টারিং করতাম, তার ফলে আমাদের ব্যাকএন্ড হিসেবে ব্যবহার করা হত। এই ফিল্টারিংটি মোটেও GraphQL ছিল না, কিন্তু এরকম কিছু ছিল - এটি প্রচুর কোয়েরি স্ট্রিং প্যারামিটারের মাধ্যমে কাজ করেছিল। এত শক্তিশালী টুল ব্যবহার করে, ব্যবহারকারীদের পক্ষে প্রতিরোধ করা কঠিন ছিল এবং অনুরোধগুলি আমাদের কাছে স্থানান্তরিত করা হত যাতে সেগুলি সরাসরি তাদের অনলাইন স্টোরের UI থেকে পাঠানো হত। পরিস্থিতিটি একটি অপ্রীতিকর আশ্চর্যের মতো এসেছিল, কারণ এই ধরনের পরিষেবা প্রদানের জন্য ভিন্ন মূল্য নির্ধারণ এবং পণ্য হিসাবে API সম্পর্কে ভিন্ন ধারণা থাকা উচিত।
3. যেহেতু API একটি মূল পণ্য হিসেবে তৈরি করা হয়নি, তাই API ডকুমেন্টেশন তৈরি এবং প্রকাশ করা হয়েছিল একটি পরবর্তী চিন্তাভাবনা হিসাবে - বিপরীত প্রকৌশলের মাধ্যমে। এই পথটি যথেষ্ট সহজ এবং সুবিধাজনক বলে মনে হচ্ছে, কিন্তু এটি চুক্তির কাজের সাথে সাংঘর্ষিক। এটি তখনই ঘটে যখন একটি নির্দিষ্ট উপাদান থাকে যার একটি পূর্ব-ইনস্টল করা অপারেটিং স্কিম থাকে। বিকাশকারী এই স্কিম এবং কাজ অনুসারে এটি বাস্তবায়ন করে, উপাদানটি পরীক্ষা করা হয়, ক্লায়েন্ট এমন একটি পণ্য পায় যা বিশ্লেষকের ধারণার সাথে মিলে যায়। বিপরীত প্রকৌশল বাজারে এমন একটি পণ্য ফেলে দেয় যা কেবল বিদ্যমান: প্রয়োজনীয় কার্যকারিতার পরিবর্তে ক্রাচ, অদ্ভুত সমাধান এবং সাইকেল সহ।
4. API-এর মাধ্যমে আসা সম্পূর্ণ অনুরোধগুলিকে Nginx বা অ্যাপ্লিকেশন সার্ভার লগ ছাড়া আর কিছুই হিসাবে বিশ্লেষণ করা যেতে পারে না। এটি আমাদের বিষয় ক্ষেত্রগুলি সনাক্ত করার অনুমতি দেয়নি, সম্ভবত ব্যবহারকারী এবং গ্রাহকদের দ্বারা ছাড়া। যদি আবেদনপত্র বা ক্লায়েন্টদের নিবন্ধন নিয়ন্ত্রণ করার কোন উপায় না থাকে, তাহলে পরিস্থিতি বিশ্লেষণ করা অসম্ভব হয়ে পড়ে। এই সমস্যাটি API-এর উন্নয়নের উপর সবচেয়ে কম প্রভাব ফেলেছে; এটি এর প্রাসঙ্গিকতা এবং কার্যকারিতা বোঝার বিষয়ে বেশি গুরুত্বপূর্ণ।

দুই নম্বর প্রচেষ্টা: REST API

২০১০ সালে, আমরা অনলাইন অ্যাকাউন্টিং সহ একটি বিনিময় ব্যবস্থা তৈরি করার চেষ্টা করেছিলাম - BukhSoft। এটা উড়েনি। তবে, ইন্টিগ্রেশন প্রক্রিয়া চলাকালীন, একটি পূর্ণাঙ্গ API আবির্ভূত হয়েছিল: একটি REST এক্সচেঞ্জ পরিষেবা, যেখানে RPC কলের আকারে ক্রিয়াকলাপ অ্যাক্সেস করার মতো কোনও স্বাধীনতা ছিল না। API-এর সাথে সমস্ত যোগাযোগ বিশ্রামের জন্য স্ট্যান্ডার্ড মোডে আনা হয়েছিল: কোয়েরি স্ট্রিংটিতে সত্তার নাম থাকে এবং এটির সাথে সম্পাদিত ক্রিয়াকলাপটি http পদ্ধতি ব্যবহার করে নির্দিষ্ট করা হয়। আমরা সত্তা আপডেটের মুহূর্ত অনুসারে ফিল্টারিং যোগ করেছি, এবং ব্যবহারকারীরা এখন তাদের সিস্টেমের সাথে প্রতিলিপি তৈরি করার ক্ষমতা অর্জন করেছেন।

একই বছরে, গুদাম এবং পণ্যের ভারসাম্য আনলোড করার জন্য একটি API উপস্থিত হয়েছিল। সিস্টেমের সবচেয়ে মূল্যবান অংশগুলি, যেমন প্রাথমিক নথির বিনিময় এবং পণ্যের ব্যালেন্স এবং মূল্যের গণনা করা ডেটা, API এর মাধ্যমে ব্যবহারকারীদের কাছে উপলব্ধ হয়ে উঠেছে।

২০১৫ সালের ডিসেম্বরে, রিটেইলসিআরএম আমাদের এপিআই অ্যাক্সেসের জন্য প্রথম তৃতীয় পক্ষের লাইব্রেরি প্রকাশ করে। এটি বেশ সক্রিয়ভাবে ব্যবহার করা শুরু হয়েছিল, যখন সামগ্রিকভাবে পরিষেবাটির জনপ্রিয়তা বৃদ্ধি পেয়েছিল, ওয়েব ইন্টারফেসের লোডের চেয়ে API-এর লোড দ্রুত বৃদ্ধি পেয়েছিল। একদিন, বৃদ্ধি লোড স্রোতে পরিণত হল।

এবং বাম দিকের তীর দ্বারা নির্দেশিত এই লাফটি আমাদের API পরিষেবা প্রদানকারী সার্ভারকে সম্পূর্ণরূপে অবাক করে দিয়েছে। এক সপ্তাহ ধরে আমরা বুঝতে পেরেছি ঠিক কী কারণে এই বোঝা তৈরি হচ্ছে। দেখা গেল যে এগুলি ক্লায়েন্ট ফ্রন্ট এন্ড থেকে আমাদের API-তে প্রেরিত একই অনুরোধ। প্রায় ৫০ জন গ্রাহক সবকিছু খেয়ে ফেলেছেন। তখনই আমরা আমাদের একটি ভুল বুঝতে পেরেছিলাম - সীমার সম্পূর্ণ অভাব।

ফলস্বরূপ, আমরা একসাথে অনুরোধের সংখ্যার উপর একটি সীমা প্রবর্তন করেছি। এখন একটি অ্যাকাউন্ট থেকে একই সময়ে দুটির বেশি অনুরোধ খোলা সম্ভব নয়। ব্যাচ ডেটা বিনিময়ের জন্য প্রতিলিপি মোডে কাজ করার জন্য এটি যথেষ্ট। এবং যারা আমাদের ব্যাকএন্ড হিসেবে ব্যবহার করতে চেয়েছিল, তারা সেই মুহূর্ত থেকে আরও বেশি করে শুল্ক মেনে চলতে বাধ্য হয়েছিল, কারণ তারা তাদের সফ্টওয়্যারে একাধিক অ্যাকাউন্টের কাজ চালু করেছিল।

আসুন এটিকে সাজিয়ে নিই।

২০১৪ সাল থেকে, বিদ্যমান API-এর চাহিদা ব্যবসার একটি গুরুত্বপূর্ণ অংশ হয়ে উঠেছে, এবং API নিজেই গ্রাহকদের সাথে ডেটা বিনিময়ে সর্বাধিক পরিমাণে ডেটা তৈরি করেছে। ২০১৫ সালে, আমরা API পরিষ্কার করার জন্য একটি প্রকল্প চালু করেছি। আমরা XML এর পরিবর্তে JSON ফর্ম্যাটটি বেছে নিয়েছি এবং পূর্ববর্তী সংস্করণ বাস্তবায়নের সময় চিহ্নিত বৈশিষ্ট্যগুলির ভিত্তিতে এটি তৈরি করতে শুরু করেছি:

1. সংস্করণ পরিচালনা করার সম্ভাবনা। ভার্সনিং আপনাকে বিদ্যমান অ্যাপ্লিকেশনটিকে প্রভাবিত না করে বা ব্যবহারকারীর অভিজ্ঞতা ব্যাহত না করে একটি নতুন সংস্করণ তৈরি করতে দেয়।
2. ব্যবহারকারীর প্রাপ্ত প্রতিক্রিয়াতেই মেটাডেটা দেখার ক্ষমতা।
3. বড় নথি বিনিময়ের সম্ভাবনা। যদি আমরা ৪-৫ হাজারেরও বেশি পজিশনের একটি ডকুমেন্ট প্রক্রিয়া করি, তাহলে এটি সার্ভারের জন্য একটি সমস্যা হয়ে দাঁড়ায়: দীর্ঘ লেনদেন, দীর্ঘ HTTP অনুরোধ। আমরা একটি বিশেষ ব্যবস্থা তৈরি করেছি যা একটি নথিকে অংশে আপডেট করতে এবং সার্ভারে পাঠিয়ে এই নথির পৃথক অবস্থান পরিচালনা করতে দেয়।
4. পূর্ববর্তী সংস্করণেও প্রতিলিপি সরঞ্জামগুলি উপলব্ধ ছিল।
5. লোড লিমিট আগের সংস্করণে ব্যবহৃত রেকের মতোই। আমরা নির্দিষ্ট সময়ের মধ্যে অনুরোধের সংখ্যা, সমান্তরাল অনুরোধের সংখ্যা এবং একটি আইপি ঠিকানা থেকে অনুরোধের সংখ্যার উপর সীমা প্রবর্তন করেছি।

তারপর থেকে, আমরা API-এর দুটি ছোট সংস্করণ প্রকাশ করেছি এবং বেশ কয়েকটি বিশেষায়িত API চালু করেছি, কিন্তু সামগ্রিক পদ্ধতি একই রয়ে গেছে। আপডেট করা এক্সচেঞ্জ ফর্ম্যাট এবং নতুন আর্কিটেকচারের ফলে API-এর ঘাটতিগুলি আরও দ্রুত সমাধান করা সম্ভব হয়েছে।

আজ মাইওয়্যারহাউস এপিআই

আজ, MyWarehouse API অনেক সমস্যার সমাধান করে:

• অনলাইন স্টোর, অ্যাকাউন্টিং সিস্টেম, ব্যাংকের সাথে ডেটা বিনিময়;
• গণনার তথ্য, প্রতিবেদন প্রাপ্তি;
• ক্লায়েন্ট অ্যাপ্লিকেশনের জন্য ব্যাকএন্ড হিসেবে ব্যবহার করুন - আমাদের মোবাইল অ্যাপ্লিকেশন এবং ডেস্কটপ ক্যাশ রেজিস্টার API এর মাধ্যমে কাজ করে
• মাইওয়্যারহাউসে ডেটা পরিবর্তন সম্পর্কে বিজ্ঞপ্তি পাঠানো — ওয়েবহুক;
• টেলিফোনি;
• আনুগত্য ব্যবস্থা।

API-এর উপর ভিত্তি করে আমাদের সিইও আসকার রাখিম্বেরদিভ গণ্ডার চার ঘন্টার মধ্যে আমি একটি টেলিগ্রাম বট লিখেছি যা API এর মাধ্যমে ব্যালেন্স টেনে আনে: github.com/arahimberdiev/com-lognex-telegram-moysklad-stock

এবার শুষ্ক সংখ্যা।

পুরাতন REST API এর জন্য আমাদের পরিসংখ্যান এখানে দেওয়া হল:

• ৪০০টি কোম্পানি;
• ৬০০ জন ব্যবহারকারী;
• প্রতিদিন ২০ লক্ষ অনুরোধ;
• ২০০ জিবি/দিন বহির্গামী ট্রাফিক।

এবং সমস্ত MyWarehouse API-এর জন্য আমরা এখানে এসেছি:

• ৭০টিরও বেশি ইন্টিগ্রেশন (এর মধ্যে কিছু এখানে দেখা যাবে) www.moysklad.ru/integratsii);
• ৪০০টি কোম্পানি;
• ১২,০০০ ব্যবহারকারী;
• প্রতিদিন ২০ লক্ষ অনুরোধ;
• প্রতিদিন ২ টিবি বহির্গামী ট্রাফিক।

পরবর্তী কি

API উন্নয়নের পরিকল্পনাগুলি সক্রিয় আলোচনার অধীনে রয়েছে। আমরা ব্যবহারকারীদের দ্বারা আমাদের দেওয়া অপারেটিং অভিজ্ঞতা বিবেচনা করার চেষ্টা করি। একবারে সবকিছু করা সবসময় সম্ভব নয়, তবে আরও সুবিধাজনক মেটাডেটা এবং কম বিস্তৃত কাঠামো সহ API-এর একটি নতুন সংস্করণ, প্রমাণীকরণের জন্য OAuth এবং ইন্টারফেসে এমবেডেড অ্যাপ্লিকেশনগুলির জন্য একটি API খুব শীঘ্রই আসছে।

আপনি MyWarehouse-এর সাথে ইন্টিগ্রেশনের ডেভেলপারদের জন্য একটি বিশেষ ওয়েবসাইটে খবরটি অনুসরণ করতে পারেন: dev.moysklad.ru সম্পর্কে.

উত্স: www.habr.com