আপনার পক্ষে বুকিং তৈরি এবং আপডেট করার জন্য অ্যাকশন সেন্টারকে কলব্যাক করার অনুমতি দেওয়ার জন্য আপনাকে একটি বুকিং সার্ভার দাঁড়াতে হবে।
- স্ট্যান্ডার্ড বাস্তবায়ন। এটি অ্যাকশন সেন্টারকে ব্যবহারকারীর পক্ষ থেকে আপনার সাথে অ্যাপয়েন্টমেন্ট, বুকিং এবং রিজার্ভেশন তৈরি করার অনুমতি দেয়।
- অপেক্ষা তালিকা বাস্তবায়ন। আপনি যখন অপেক্ষা তালিকা পাইলট প্রোগ্রামে অংশগ্রহণ করেন তখন এটি ব্যবহার করা হয়। এটি অ্যাকশন সেন্টারকে অপেক্ষার অনুমান পুনরুদ্ধার করতে এবং ব্যবহারকারীর পক্ষে অপেক্ষা তালিকা এন্ট্রি তৈরি করতে দেয়। ওয়েটলিস্টের জন্য একটি বুকিং সার্ভার বাস্তবায়ন করতে অনুগ্রহ করে ইমপ্লিমেন্ট ওয়েটলিস্ট বুকিং সার্ভার দেখুন।
আপনার স্যান্ডবক্স এবং প্রোডাকশন বুকিং সার্ভারের সাথে সংযোগটি কীভাবে কনফিগার করবেন তা শিখতে অংশীদার পোর্টাল ডকুমেন্টেশন দেখুন।
একটি REST API ইন্টারফেস প্রয়োগ করুন
REST এর উপর ভিত্তি করে একটি API ইন্টারফেস প্রয়োগ করুন এটি Google কে HTTP এর মাধ্যমে বুকিং সার্ভারের অনুরোধ পাঠাতে দেয়৷
শুরু করতে, একটি ডেভেলপমেন্ট বা স্যান্ডবক্স বুকিং সার্ভার সেট আপ করুন যা অ্যাকশন সেন্টার স্যান্ডবক্স পরিবেশের সাথে সংযুক্ত হতে পারে। স্যান্ডবক্স সার্ভার সম্পূর্ণরূপে পরীক্ষা করা হলে শুধুমাত্র একটি উৎপাদন পরিবেশে যান।
পদ্ধতি
প্রতিটি ধরনের বুকিং সার্ভারের জন্য, আপনার প্রান্তে আলাদা আলাদা API পদ্ধতির প্রয়োজন। ঐচ্ছিকভাবে, আপনি API বাস্তবায়নের সাথে শুরু করতে প্রোটো ফর্ম্যাটে পরিষেবা সংজ্ঞা ডাউনলোড করতে পারেন। নিম্নলিখিত সারণীগুলি প্রতিটি বাস্তবায়নের পদ্ধতিগুলি দেখায় এবং পরিষেবা প্রোটো ফর্ম্যাটের লিঙ্কগুলি অন্তর্ভুক্ত করে৷
স্ট্যান্ডার্ড বাস্তবায়ন |
---|
স্ট্যান্ডার্ড পরিষেবা সংজ্ঞা প্রোটো পরিষেবা সংজ্ঞা ফাইল ডাউনলোড করুন। |
পদ্ধতি | HTTP অনুরোধ |
---|---|
স্বাস্থ্য পরীক্ষা | পান /v3/স্বাস্থ্য পরীক্ষা/ |
ব্যাচ উপলভ্যতা লুকআপ | POST /v3/ব্যাচ উপলভ্যতা লুকআপ/ |
বুকিং তৈরি করুন | POST /v3/CreateBooking/ |
বুকিং আপডেট করুন | পোস্ট /v3/আপডেটবুকিং/ |
GetBooking Status | পোস্ট /v3/গেটবুকিং স্ট্যাটাস/ |
লিস্টবুকিং | পোস্ট /v3/লিস্টবুকিংস/ |
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 স্ট্যাটাস কোড
স্ট্যান্ডার্ড বাস্তবায়নের জন্য, সম্ভাব্য ব্যবসায়িক লজিক ত্রুটিগুলি বুকিং ব্যর্থতায় ধরা হয় এবং সেগুলি 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
প্রচেষ্টা ব্যর্থ হয় এবং একই অনুরোধ পুনরায় পাঠানো হয়, আপনার ব্যাকএন্ড এই ক্ষেত্রে এটি পুনরায় চেষ্টা করা উচিত।
বুদ্ধিমত্তার প্রয়োজনীয়তা সমস্ত পদ্ধতির ক্ষেত্রে প্রযোজ্য যা রাষ্ট্রকে পরিবর্তন করে।