বুকিং সার্ভার প্রয়োগ করুন: API v2

দ্রষ্টব্য: এই পৃষ্ঠাটি API v2 এর সাথে বুকিং সার্ভারটি কীভাবে প্রয়োগ করা যায় তা বর্ণনা করে। সর্বশেষ সংস্করণ ব্যবহার করার জন্য নির্দেশাবলীর জন্য বুকিং সার্ভার বাস্তবায়ন দেখুন।

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

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 পদ্ধতিগুলি আপনার প্রান্তে প্রয়োগ করা প্রয়োজন :

• গ্রহণযোগ্যতা যাচাই
• বুকিং তৈরি করুন
• বুকিং আপডেট করুন
• GetBooking Status
• লিস্টবুকিং

এই 5টি পদ্ধতি 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) {}
}

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

চিত্র 1: একটি স্লট থেকে একটি বুকিং তৈরি করুন

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

জাভাতে কঙ্কাল বাস্তবায়ন

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

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

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

যখন একটি অংশীদার ব্যাকএন্ড gRPC অনুরোধগুলি পরিচালনা করে তখন দুই ধরনের ত্রুটি ঘটতে পারে: অপ্রত্যাশিত ত্রুটি যা ভুল তথ্য থেকে উদ্ভূত হয়; এবং ব্যবসায়িক যুক্তির ত্রুটি যা একটি বুকিং তৈরি বা আপডেট করার অক্ষমতা নির্দেশ করে ( বুকিং ব্যর্থতা দেখুন), যেমন, অনুরোধকৃত স্লট অনুপলব্ধ হলে।

অপ্রত্যাশিত ত্রুটি, যদি সম্মুখীন হয়, তাহলে ক্যানোনিকাল gRPC ত্রুটি কোড ব্যবহার করে ক্লায়েন্টকে ফেরত দেওয়া উচিত। উদাহরণ অন্তর্ভুক্ত কিন্তু সীমাবদ্ধ নয়:

• INVALID_ARGUMENT RPC-তে ব্যবহার করা হয় যেমন CheckAvailability এবং CreateLease, এবং প্রদত্ত স্লটে অবৈধ তথ্য থাকলে তা ফেরত দেওয়া উচিত।
• NOT_FOUND ব্যবহার করা হয় RPC যেমন CreateBooking এবং ListBookings, এবং যদি প্রদত্ত শনাক্তকারী অংশীদারের কাছে অজানা থাকে তাহলে ফেরত দেওয়া উচিত।

এর ক্যানোনিকাল gRPC ত্রুটি কোডগুলির জন্য প্রতিটি পদ্ধতির রেফারেন্স দেখুন বা সম্পূর্ণ স্ট্যাটাস কোড তালিকা দেখুন।

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

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

অদম্যতা

নেটওয়ার্কের মাধ্যমে যোগাযোগ সর্বদা নির্ভরযোগ্য হয় না এবং কোনো প্রতিক্রিয়া না পাওয়া গেলে Google রিজার্ভ RPC পুনরায় চেষ্টা করতে পারে। এই কারণে, সমস্ত RPC যেগুলি পরিবর্তন করে (CreateBooking, UpdateBooking) বুদ্ধিমত্তাহীন হতে হবে৷ এই RPCগুলির জন্য অনুরোধের বার্তাগুলির মধ্যে আইডেমপোটেন্সি টোকেন অন্তর্ভুক্ত থাকে যাতে অনুরোধটিকে স্বতন্ত্রভাবে সনাক্ত করা যায় এবং অংশীদারকে পুনরায় চেষ্টা করা RPC (একটি বুকিং তৈরি করার অভিপ্রায় সহ) এবং দুটি পৃথক বুকিংয়ের মধ্যে পার্থক্য করার অনুমতি দেয়।

উদাহরণ অন্তর্ভুক্ত কিন্তু সীমাবদ্ধ নয়:

• একটি সফল ক্রিয়েটবুকিং 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	DNS:mapsbooking.businesslink-3.net

এই ক্লায়েন্ট সার্টিফিকেট ছাড়া সংযোগ প্রচেষ্টা অংশীদার সার্ভার দ্বারা প্রত্যাখ্যান করা উচিত.

ক্লায়েন্ট সার্টিফিকেট যাচাই করতে, সার্ভার বিশ্বস্ত ক্লায়েন্ট রুট সার্টিফিকেটের একটি সেটের উপর নির্ভর করে। আপনি Mozilla এর মতো একটি কর্তৃপক্ষের কাছ থেকে বিশ্বস্ত রুটগুলির এই সেটটি পেতে বা Google ইন্টারনেট কর্তৃপক্ষ G2 দ্বারা বর্তমানে প্রস্তাবিত রুটগুলির সেট ইনস্টল করতে পারেন৷ উভয় ক্ষেত্রেই, আপনাকে মাঝে মাঝে রুট সার্টিফিকেট ম্যানুয়ালি আপডেট করতে হতে পারে।

জিআরপিসি হেলথ চেকিং প্রোটোকল বাস্তবায়ন করুন

GRPC হেলথ চেকিং প্রোটোকল বাস্তবায়ন করুন। এই প্রোটোকল Google কে আপনার gRPC বাস্তবায়নের ব্যাকএন্ড স্থিতি নিরীক্ষণ করতে সক্ষম করে। পরিষেবার স্পেসিফিকেশন GRPC বিতরণের অংশ। GRPC নামকরণের নিয়ম অনুসরণ করে, স্বাস্থ্য পরীক্ষা কলে পরিষেবাটির নাম হল ext.maps.booking.partner.v2.BookingService for API v2, অথবা ext.maps.booking.partner.v0.BookingService API v0 এর জন্য৷ স্বাস্থ্য পরীক্ষা অন্যান্য শেষ পয়েন্টের মতো একই URL এবং PORT-এ চালানো উচিত।

দ্রষ্টব্য: রুবিতে রেফারেন্স বাস্তবায়নগুলি দেখুন।

অন্যান্য সংস্করণ

API-এর অন্যান্য সংস্করণগুলির জন্য ডকুমেন্টেশনের জন্য, নিম্নলিখিত পৃষ্ঠাগুলি দেখুন: * API v3 * API v0