ধাপ 4: বুকিং সার্ভার বাস্তবায়ন করুন

আপনার পক্ষে বুকিং তৈরি এবং আপডেট করার জন্য অ্যাকশন সেন্টারকে কলব্যাক করার অনুমতি দেওয়ার জন্য আপনাকে একটি বুকিং সার্ভার দাঁড়াতে হবে।

• স্ট্যান্ডার্ড বাস্তবায়ন। এটি অ্যাকশন সেন্টারকে ব্যবহারকারীর পক্ষ থেকে আপনার সাথে অ্যাপয়েন্টমেন্ট, বুকিং এবং রিজার্ভেশন তৈরি করার অনুমতি দেয়।

আপনার স্যান্ডবক্স এবং প্রোডাকশন বুকিং সার্ভারের সাথে সংযোগটি কীভাবে কনফিগার করবেন তা শিখতে অংশীদার পোর্টাল ডকুমেন্টেশন দেখুন।

একটি REST API ইন্টারফেস প্রয়োগ করুন

REST এর উপর ভিত্তি করে একটি API ইন্টারফেস প্রয়োগ করুন এটি Google কে HTTP এর মাধ্যমে বুকিং সার্ভারের অনুরোধ পাঠাতে দেয়৷

শুরু করতে, একটি ডেভেলপমেন্ট বা স্যান্ডবক্স বুকিং সার্ভার সেট আপ করুন যা অ্যাকশন সেন্টার স্যান্ডবক্স পরিবেশের সাথে সংযুক্ত হতে পারে। স্যান্ডবক্স সার্ভার সম্পূর্ণরূপে পরীক্ষা করা হলে শুধুমাত্র একটি উৎপাদন পরিবেশে যান।

পদ্ধতি

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

API সম্পদ

সংরক্ষণ

নিম্নোক্ত রিসোর্স প্রকারগুলি স্ট্যান্ডার্ড বাস্তবায়নে ব্যবহৃত হয়:

• স্লট : একটি ইনভেন্টরি স্লট।
• বুকিং : একটি ইনভেন্টরি স্লটের জন্য একটি অ্যাপয়েন্টমেন্ট।

প্রবাহ: একটি বুকিং তৈরি করুন

এই বিভাগে স্ট্যান্ডার্ড বাস্তবায়নের জন্য কিভাবে বুকিং তৈরি করতে হয় তা কভার করে।

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

নিরাপত্তা এবং প্রমাণীকরণ

আপনার বুকিং সার্ভারের সাথে সমস্ত যোগাযোগ HTTPS-এর মাধ্যমে হয়, তাই এটি অপরিহার্য যে আপনার সার্ভারের একটি বৈধ TLS শংসাপত্র রয়েছে যা এর DNS নামের সাথে মেলে৷ আপনার সার্ভার সেট আপ করতে সাহায্য করার জন্য, আমরা একটি সর্বজনীনভাবে উপলব্ধ SSL/TLS যাচাইকরণ টুল ব্যবহার করার পরামর্শ দিই, যেমন Qualys' SSL সার্ভার টেস্ট ।

আপনার বুকিং সার্ভারে Google যে সমস্ত অনুরোধ করবে তা HTTP মৌলিক প্রমাণীকরণ ব্যবহার করে প্রমাণীকরণ করা হবে। আপনার বুকিং সার্ভারের জন্য মৌলিক প্রমাণীকরণ শংসাপত্র (ব্যবহারকারীর নাম এবং পাসওয়ার্ড) অংশীদার পোর্টালের মধ্যে বুকিং সার্ভার কনফিগারেশন পৃষ্ঠায় প্রবেশ করা যেতে পারে। প্রতি ছয় মাস অন্তর পাসওয়ার্ড ঘোরাতে হবে।

নমুনা কঙ্কাল বাস্তবায়ন

শুরু করতে, Node.js এবং Java ফ্রেমওয়ার্কের জন্য লেখা বুকিং সার্ভারের নিম্নলিখিত নমুনা কঙ্কাল দেখুন:

• Node.js কঙ্কাল js-maps-booking-rest-server-v3-skeleton
• জাভা কঙ্কাল java-maps-booking-rest-server-v3-skeleton

এই সার্ভারগুলি REST পদ্ধতিগুলিকে আটকে দিয়েছে।

প্রয়োজনীয়তা

HTTP ত্রুটি এবং ব্যবসায়িক যুক্তি ত্রুটি

যখন আপনার ব্যাকএন্ড HTTP অনুরোধগুলি পরিচালনা করে, তখন দুই ধরনের ত্রুটি ঘটতে পারে।

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

স্ট্যান্ডার্ড বাস্তবায়নের জন্য, সম্ভাব্য ব্যবসায়িক লজিক ত্রুটিগুলি বুকিং ব্যর্থতায় ধরা হয় এবং সেগুলি HTTP প্রতিক্রিয়াতে ফেরত দেওয়া হয়। একটি সংস্থান তৈরি বা আপডেট করার সময় ব্যবসায়িক যুক্তি ত্রুটির সম্মুখীন হতে পারে। উদাহরণস্বরূপ, আপনি যখন CreateBooking বা UpdatingBooking পদ্ধতিগুলি পরিচালনা করেন। উদাহরণগুলির মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত, কিন্তু সীমাবদ্ধ নয়:

• অনুরোধকৃত স্লট আর উপলব্ধ না হলে SLOT_UNAVAILABLE ব্যবহার করা হয়।
• PAYMENT_ERROR_CARD_TYPE_REJECTED ব্যবহার করা হয় যদি প্রদত্ত ক্রেডিট কার্ডের ধরন গ্রহণ করা না হয়।

অদম্যতা

নেটওয়ার্কের মাধ্যমে যোগাযোগ সর্বদা নির্ভরযোগ্য নয় এবং কোনো প্রতিক্রিয়া না পেলে Google HTTP অনুরোধের জন্য পুনরায় চেষ্টা করতে পারে। এই কারণে, সমস্ত পদ্ধতি যেগুলি রাষ্ট্রকে পরিবর্তন করে তা অবশ্যই অদম্য হতে হবে:

• CreateBooking
• UpdateBooking

UpdateBooking ব্যতীত প্রতিটি অনুরোধ বার্তার জন্য, অনুরোধটিকে স্বতন্ত্রভাবে সনাক্ত করার জন্য idempotency টোকেন অন্তর্ভুক্ত করা হয়। এটি আপনাকে একটি একক অনুরোধ এবং দুটি পৃথক অনুরোধ তৈরি করার অভিপ্রায় সহ একটি পুনরায় চেষ্টা করা REST কলের মধ্যে পার্থক্য করতে দেয়৷ UpdateBooking যথাক্রমে তাদের বুকিং এন্ট্রি আইডি দ্বারা স্বতন্ত্রভাবে চিহ্নিত করা হয়, তাই তাদের অনুরোধে কোন idempotency টোকেন অন্তর্ভুক্ত করা হয় না।

বুকিং সার্ভার কিভাবে অদম্যতা পরিচালনা করে তার কিছু উদাহরণ নিচে দেওয়া হল:

• একটি সফল CreateBooking HTTP প্রতিক্রিয়া তৈরি করা বুকিং অন্তর্ভুক্ত। কিছু ক্ষেত্রে, বুকিং প্রবাহের অংশ হিসাবে অর্থপ্রদান প্রক্রিয়া করা হয়। যদি ঠিক একই CreateBookingRequest দ্বিতীয়বার প্রাপ্ত হয় (একই idempotency_token সহ), তাহলে একই CreateBookingResponse ফেরত দিতে হবে। কোন দ্বিতীয় বুকিং তৈরি করা হয় না, এবং প্রযোজ্য হলে ব্যবহারকারীকে ঠিক একবার চার্জ করা হয়।

  মনে রাখবেন যদি একটি CreateBooking প্রচেষ্টা ব্যর্থ হয় এবং একই অনুরোধ পুনরায় পাঠানো হয়, আপনার ব্যাকএন্ড এই ক্ষেত্রে এটি পুনরায় চেষ্টা করা উচিত।

বুদ্ধিমত্তার প্রয়োজনীয়তা সমস্ত পদ্ধতির ক্ষেত্রে প্রযোজ্য যা রাষ্ট্রকে পরিবর্তন করে।