আপনার পক্ষ থেকে একটি বুকিং সার্ভার সেট আপ করলে অ্যাকশন সেন্টার ব্যবহারকারীর পক্ষ থেকে আপনার সাথে অ্যাপয়েন্টমেন্ট/বুকিং/রিজার্ভেশন তৈরি করতে পারবে।
gRPC-এর উপর ভিত্তি করে একটি API ইন্টারফেস বাস্তবায়ন করুন
অনুগ্রহ করে মনে রাখবেন: সমস্ত নতুন অংশীদারদের gRPC API এর পরিবর্তে REST API ইন্টারফেস ব্যবহার করা উচিত।
gRPC ভিত্তিক একটি API ইন্টারফেস বাস্তবায়ন করুন। এটি Google কে বুকিং অনুরোধ পাঠাতে সাহায্য করে। API পৃষ্ঠটি gRPC এর প্রোটোবফ ভিত্তিক IDL ব্যবহার করে সংজ্ঞায়িত করা হয়।
আমরা আমাদের নতুন অংশীদারদের API v2 এর একটি প্রস্তাবিত সেট বাস্তবায়ন করতে বলছি। অংশীদাররা তাদের পরিকাঠামোর জন্য যে URL এবং PORT সবচেয়ে ভালো কাজ করে তা নির্বাচন করতে পারে।
এই বিভাগটি API v2 এর একটি প্রস্তাবিত সেট উপস্থাপন করে। এটি সেই অংশীদারদের জন্য প্রযোজ্য যারা API v0 বাস্তবায়ন করেনি। আমাদের বর্তমান অংশীদাররা যারা API v0 বাস্তবায়ন করেছে, আরও জানতে অনুগ্রহ করে অ্যাকশন সেন্টারে যোগাযোগ করুন।
API বাস্তবায়ন শুরু করতে নীচের প্রোটো ফর্ম্যাটে পরিষেবা সংজ্ঞাটি ডাউনলোড করুন।
API রিসোর্স
এই বাস্তবায়নে ব্যবহৃত নিম্নলিখিত রিসোর্সের ধরণগুলির সাথে নিজেকে পরিচিত করুন:
পদ্ধতি
gRPC সার্ভারের জন্য আপনার পক্ষ থেকে নিম্নলিখিত API পদ্ধতিগুলি প্রয়োগ করা প্রয়োজন :
এই ৫টি পদ্ধতি BookingService RPC-এর প্রয়োজনীয় সেট নির্ধারণ করে:
// Manages slot availability, leases and bookings for an inventory of
// appointments
service BookingService {
// Gets availability information for an appointment slot
rpc CheckAvailability(CheckAvailabilityRequest)
returns (CheckAvailabilityResponse) {}
// Creates a booking
rpc CreateBooking(CreateBookingRequest) returns (CreateBookingResponse) {}
// Updates an existing booking
rpc UpdateBooking(UpdateBookingRequest) returns (UpdateBookingResponse) {}
// Gets status for an existing booking
rpc GetBookingStatus(GetBookingStatusRequest)
returns (GetBookingStatusResponse) {}
// Lists all upcoming bookings for a user
rpc ListBookings(ListBookingsRequest) returns (ListBookingsResponse) {}
}
প্রবাহ: একটি বুকিং তৈরি করুন
বুকিং তৈরি করার সময়, Google অংশীদারকে ব্যবহারকারীর প্রদত্ত নাম, পদবি, ফোন নম্বর এবং ইমেল পাঠাবে। অংশীদারের দৃষ্টিকোণ থেকে এটিকে অতিথি চেকআউট হিসাবে বিবেচনা করা উচিত কারণ অ্যাকশন সেন্টারের অংশীদারের সিস্টেমে ব্যবহারকারীর অ্যাকাউন্ট খোঁজার কোনও উপায় নেই। অংশীদারের বুকিং সিস্টেমের জন্য আসা বুকিংয়ের মতোই চূড়ান্ত বুকিং অংশীদারের ব্যবসায়ীদের তাদের সিস্টেমে দেখানো উচিত।
জাভাতে কঙ্কাল বাস্তবায়ন
শুরু করার জন্য, আমরা জাভাতে একটি স্কেলিটন জিআরপিসি সার্ভার প্রদান করি যা কম্পাইল এবং ইনস্টল করা যেতে পারে। নমুনা > জিআরপিসি রেফারেন্স বাস্তবায়ন বিভাগের অধীনে এটি পরীক্ষা করে দেখুন। এই সার্ভারটি প্রমাণীকরণ এবং স্বাস্থ্য পরিষেবা সহ ইন্টিগ্রেশন সমর্থন করার জন্য প্রয়োজনীয় জিআরপিসি পদ্ধতিগুলিকে স্টাব আউট করেছে।
আবশ্যকতা
জিআরপিসি ত্রুটি এবং ব্যবসায়িক যুক্তি ত্রুটি
যখন কোনও পার্টনার ব্যাকএন্ড gRPC অনুরোধ পরিচালনা করে তখন দুই ধরণের ত্রুটি ঘটতে পারে: ভুল ডেটা থেকে উদ্ভূত অপ্রত্যাশিত ত্রুটি; এবং ব্যবসায়িক লজিক ত্রুটি যা বুকিং তৈরি বা আপডেট করার অক্ষমতা নির্দেশ করে ( বুকিং ব্যর্থতা দেখুন), যেমন, যদি অনুরোধ করা স্লটটি অনুপলব্ধ থাকে।
অপ্রত্যাশিত ত্রুটির সম্মুখীন হলে, ক্যানোনিকাল gRPC ত্রুটি কোড ব্যবহার করে ক্লায়েন্টকে ফেরত পাঠানো উচিত। উদাহরণগুলির মধ্যে রয়েছে কিন্তু সীমাবদ্ধ নয়:
- INVALID_ARGUMENT RPC যেমন CheckAvailability এবং CreateLease-এ ব্যবহৃত হয় এবং যদি প্রদত্ত স্লটে অবৈধ তথ্য থাকে তবে তা ফেরত পাঠানো উচিত।
- NOT_FOUND RPC যেমন CreateBooking এবং ListBookings-এ ব্যবহৃত হয় এবং যদি প্রদত্ত শনাক্তকারী অংশীদারের কাছে অজানা থাকে তবে তা ফেরত পাঠানো উচিত।
প্রতিটি পদ্ধতির ক্যানোনিকাল gRPC ত্রুটি কোডের রেফারেন্স দেখুন অথবা সম্পূর্ণ স্ট্যাটাস কোড তালিকা দেখুন।
বিপরীতে, ব্যবসায়িক লজিক ত্রুটিগুলি Booking Failure -এ ধরা উচিত এবং RPC প্রতিক্রিয়ায় ফেরত পাঠানো উচিত। কোনও রিসোর্স তৈরি বা আপডেট করার সময়, অর্থাৎ RPC CreateBooking এবং UpdatingBooking পরিচালনা করার সময় ব্যবসায়িক লজিক ত্রুটির সম্মুখীন হতে পারে। উদাহরণগুলির মধ্যে রয়েছে কিন্তু সীমাবদ্ধ নয়:
- অনুরোধকৃত স্লটটি আর উপলব্ধ না থাকলে SLOT_UNAVAILABLE ব্যবহার করা হয়।
- প্রদত্ত ক্রেডিট কার্ডের ধরণ গ্রহণ না করা হলে PAYMENT_ERROR_CARD_TYPE_REJECTED ব্যবহার করা হয়।
অদক্ষতা
নেটওয়ার্কের মাধ্যমে যোগাযোগ সবসময় নির্ভরযোগ্য নয় এবং কোনও প্রতিক্রিয়া না পেলে Google Reserve RPC পুনরায় চেষ্টা করতে পারে। এই কারণে, যে সমস্ত RPC-র অবস্থা পরিবর্তন করা হয় (CreateBooking, UpdateBooking) তাদের অক্ষমতা থাকতে হবে। এই RPC-গুলির জন্য অনুরোধ বার্তাগুলিতে অক্ষমতা টোকেন অন্তর্ভুক্ত থাকে যা অনুরোধটিকে অনন্যভাবে সনাক্ত করতে এবং অংশীদারকে পুনরায় চেষ্টা করা RPC (একটি বুকিং তৈরি করার উদ্দেশ্যে) এবং দুটি পৃথক বুকিংয়ের মধ্যে পার্থক্য করতে দেয়।
উদাহরণগুলির মধ্যে রয়েছে কিন্তু সীমাবদ্ধ নয়:
- একটি সফল CreateBooking RPC প্রতিক্রিয়াতে তৈরি করা বুকিং অন্তর্ভুক্ত থাকে এবং কিছু ক্ষেত্রে, বুকিং প্রবাহের অংশ হিসাবে অর্থপ্রদান প্রক্রিয়া করা হয়। যদি একই CreateBookingRequest দ্বিতীয়বার (
idempotency_tokenসহ) গৃহীত হয়, তাহলে একই CreateBookingResponse ফেরত দিতে হবে। দ্বিতীয়বার বুকিং তৈরি করা হয় না এবং প্রযোজ্য হলে ব্যবহারকারীকে ঠিক একবার চার্জ করা হয়। মনে রাখবেন যে যদি CreateBooking প্রচেষ্টা ব্যর্থ হয়, তাহলে একই অনুরোধ আবার পাঠানো হলে অংশীদার ব্যাকএন্ড পুনরায় চেষ্টা করা উচিত।
আইডেম্পোটেন্সি টোকেন ধারণকারী সকল পদ্ধতির ক্ষেত্রে আইডেম্পোটেন্সির প্রয়োজনীয়তা প্রযোজ্য।
gRPC সার্ভার নিরাপত্তা এবং প্রমাণীকরণ
অ্যাকশন সেন্টার থেকে আপনার ব্যাকএন্ডে কলগুলি সার্টিফিকেট-ভিত্তিক, পারস্পরিক ক্লায়েন্ট/সার্ভার প্রমাণীকরণ সহ SSL/TLS ব্যবহার করে সুরক্ষিত করতে হবে। এর জন্য আপনার gRPC বাস্তবায়নের জন্য একটি বৈধ সার্ভার সার্টিফিকেট ব্যবহার করা এবং একটি বৈধ ক্লায়েন্ট সার্টিফিকেট গ্রহণ করা প্রয়োজন।
সার্ভার সার্টিফিকেট: পার্টনার সার্ভারে সার্ভারের ডোমেন নামের সাথে যুক্ত একটি বৈধ সার্ভার সার্টিফিকেট থাকতে হবে ( স্বীকৃত রুট CA-এর এই তালিকাটি দেখুন)। GRPC সার্ভার বাস্তবায়নগুলি একটি সার্টিফিকেট চেইন পরিবেশন করবে যা রুট সার্টিফিকেট পর্যন্ত নিয়ে যাবে। এটি সম্পন্ন করার সবচেয়ে সহজ উপায় হল PEM ফর্ম্যাটে পার্টনারের ওয়েব হোস্ট দ্বারা প্রদত্ত মধ্যবর্তী সার্টিফিকেট(গুলি) সার্ভার সার্টিফিকেটের সাথে (PEM ফর্ম্যাটেও) যুক্ত করা।
সংযোগের সময় সার্ভার সার্টিফিকেট যাচাই করা হয় এবং স্ব-স্বাক্ষরিত সার্টিফিকেট গ্রহণ করা হয় না। যতক্ষণ পর্যন্ত সার্টিফিকেট বৈধ থাকে ততক্ষণ পর্যন্ত প্রকৃত সার্টিফিকেটের বিষয়বস্তু পরীক্ষা করা হয় না। আপনি নিম্নলিখিত কমান্ডের মাধ্যমে আপনার সার্টিফিকেটের বৈধতা পরীক্ষা করতে পারেন:
echo "" | openssl s_client -connect YOUR_URL:YOUR_PORT -showcerts -CApath /etc/ssl/certs
ক্লায়েন্ট সার্টিফিকেট: আমাদের (Google হিসেবে) অংশীদারের কাছে প্রমাণীকরণ করার জন্য, আমরা Google ইন্টারনেট কর্তৃপক্ষ G2 ( CA সার্টিফিকেট ) দ্বারা জারি করা একটি ক্লায়েন্ট সার্টিফিকেট প্রদান করি যার মধ্যে নিম্নলিখিত বৈশিষ্ট্য রয়েছে:
| মাঠ | মূল্য |
|---|---|
CN | mapsbooking.businesslink-3.net সম্পর্কে |
SAN | ডিএনএস: ম্যাপসবুকিং.বিজনেসলিঙ্ক-৩.নেট |
এই ক্লায়েন্ট সার্টিফিকেট ছাড়া সংযোগ প্রচেষ্টা অংশীদার সার্ভার দ্বারা প্রত্যাখ্যান করা উচিত।
ক্লায়েন্ট সার্টিফিকেট যাচাই করার জন্য, সার্ভার বিশ্বস্ত ক্লায়েন্ট রুট সার্টিফিকেটের একটি সেটের উপর নির্ভর করে। আপনি Mozilla এর মতো কোনও কর্তৃপক্ষ থেকে বিশ্বস্ত রুটগুলির এই সেটটি পেতে পারেন অথবা Google ইন্টারনেট অথরিটি G2 দ্বারা বর্তমানে সুপারিশকৃত রুটগুলির সেটটি ইনস্টল করতে পারেন। উভয় ক্ষেত্রেই, আপনাকে মাঝে মাঝে রুট সার্টিফিকেটগুলি ম্যানুয়ালি আপডেট করতে হতে পারে।
জিআরপিসি স্বাস্থ্য পরীক্ষা প্রোটোকল বাস্তবায়ন করুন
GRPC হেলথ চেকিং প্রোটোকল বাস্তবায়ন করুন। এই প্রোটোকলটি Google কে আপনার gRPC বাস্তবায়নের ব্যাকএন্ড স্ট্যাটাস পর্যবেক্ষণ করতে সক্ষম করে। পরিষেবা স্পেসিফিকেশন GRPC বিতরণের অংশ। GRPC নামকরণ কনভেনশন অনুসরণ করে, স্বাস্থ্য পরীক্ষা কলগুলিতে পরিষেবার নাম হল ext.maps.booking.partner.v2.BookingService for API v2, অথবা ext.maps.booking.partner.v0.BookingService for API v0। স্বাস্থ্য পরীক্ষাটি অন্যান্য এন্ডপয়েন্টের মতো একই URL এবং PORT-তে চালানো উচিত।
অন্যান্য সংস্করণ
API-এর অন্যান্য সংস্করণের ডকুমেন্টেশনের জন্য, নিম্নলিখিত পৃষ্ঠাগুলি দেখুন: * API v3 * API v0