অংশীদার সার্ভার

মূল্য নির্ধারণ এবং প্রাপ্যতার তথ্য সমন্বিত করতে, পার্টনারদের পার্টনার এপিআই (Partner API) প্রয়োগ করতে হবে। এই ইন্টারফেসটি REST-ভিত্তিক এবং গুগলকে HTTP-এর মাধ্যমে লাইভ কল পাঠানোর সুযোগ দেয়। যদিও প্রতিটি এপিআই মেথডের বিস্তারিত বিবরণ রেফারেন্স বিভাগে বর্ণনা করা হয়েছে, তবে এর সাধারণ ব্যবহার সংক্রান্ত তথ্য আপনি পরবর্তীতে খুঁজে পাবেন।

অনুরোধ ও প্রতিক্রিয়া বিন্যাস

প্রাথমিকভাবে শুধুমাত্র JSON ফরম্যাট সমর্থন করা হবে। যদি অতিরিক্ত অনুরোধ বা প্রতিক্রিয়া ফরম্যাটের প্রয়োজন হয়, তবে আপনার ব্যবহারের ক্ষেত্রটি নিয়ে আলোচনা করতে transport-help@google.com- এ ট্র্যাভেল ট্রান্সপোর্ট টিমের সাথে যোগাযোগ করুন।

অনুরোধগুলি HTTP POST পদ্ধতি ব্যবহার করে পাঠানো হবে এবং অনুরোধ বার্তাটি POST বডিতে থাকবে।

উল্লেখ্য যে, কাঠামোগত স্বচ্ছতার জন্য, এপিআই ইন্টারফেস ডকুমেন্টেশন প্রোটোকল বাফার মেসেজ ডেফিনিশন হিসেবে প্রদান করা হয়, এবং একটি প্রোটোকল বাফার মেসেজ ডেফিনিশনকে JSON অবজেক্টে অনুবাদ করা হয় ক্যানোনিকাল JSON ম্যাপিং দ্বারা, যেখানে ডিফল্ট মানসহ ফিল্ড নির্গত করার এবং lowerCamelCase নামের পরিবর্তে প্রোটো ফিল্ডের নাম ব্যবহার করার অপশনগুলো ব্যবহৃত হয়।

প্রমাণীকরণ

গুগল HTTP ডাইজেস্ট অথেন্টিকেশন, OAuth 2.0 এবং ক্লায়েন্ট সার্টিফিকেট অথেন্টিকেশন সমর্থন করে ( পার্টনার কনফিগারেশন দেখুন)। এপিআই টেস্টিংয়ের সময় পার্টনারদের গুগলকে সঠিক ক্রেডেনশিয়াল প্রদান করতে হবে:

  • ডাইজেস্টের জন্য: ইউজারনেম ও পাসওয়ার্ড।
  • OAuth 2.0-এর জন্য: ক্লায়েন্ট_আইডি এবং ক্লায়েন্ট_সিক্রেট।
  • সার্টিফিকেটের জন্য: একটি SSL ক্লায়েন্ট সার্টিফিকেট।

স্ট্যাটাস কোড এবং ত্রুটি পরিচালনা

সাধারণত, HTTP রেসপন্সে নিম্নলিখিত স্ট্যাটাস কোডগুলো ফেরত আসতে পারে:

HTTP কোড HTTP বর্ণনা নোট
2xx ঠিক আছে এটি কোনো ত্রুটি নয়; সফল হলে এটি ফেরত দেওয়া হয়। রেসপন্স বডিতে একটি সফল ফলাফল (যেমন, TripOptionsResult) থাকার কথা, কোনো ত্রুটিপূর্ণ রেসপন্স নয় ।
৪০০ খারাপ অনুরোধ প্রাপ্ত অনুরোধটি অবৈধ ছিল। রেসপন্স বডিতে ত্রুটির অতিরিক্ত বিবরণ ফেরত দেওয়ার জন্য মেথড-নির্দিষ্ট ত্রুটি রেসপন্স ব্যবহার করা উচিত। সাধারণত শুধুমাত্র তখনই HTTP 400 ব্যবহার করা উচিত, যখন গুগল কোনো প্রযুক্তিগত ত্রুটি করে (উদাহরণস্বরূপ, অনুরোধে কোনো ফিল্ডের ভুল নামকরণ)।
৪০৩ নিষিদ্ধ অনুমতি প্রত্যাখ্যাত/নিষিদ্ধ (কলার পরিচিত এবং প্রত্যাখ্যাত)। কোনো রিসোর্স নিঃশেষ হয়ে যাওয়ার কারণে প্রত্যাখানের ক্ষেত্রে এই প্রতিক্রিয়াটি ব্যবহার করা যাবে না (সেইসব ত্রুটির জন্য পরিবর্তে 'Too Many Requests' ব্যবহার করুন)। কলারকে শনাক্ত করা না গেলে 'Forbidden' ব্যবহার করা যাবে না (সেইসব ত্রুটির জন্য পরিবর্তে 'Unauthorized' ব্যবহার করুন)।
৪০৪ খুঁজে পাওয়া যায়নি অনুরোধকৃত রিসোর্সটি খুঁজে পাওয়া যায়নি। রেসপন্স বডিতে অতিরিক্ত ত্রুটির বিবরণ ফেরত দেওয়ার জন্য মেথড-নির্দিষ্ট ত্রুটি রেসপন্স ব্যবহার করা উচিত।
৪২৯ অনেক বেশি অনুরোধ কোনো একটি রিসোর্স শেষ হয়ে গেছে, সম্ভবত ব্যবহারকারী-ভিত্তিক কোটা।
৫০০ অভ্যন্তরীণ সার্ভার ত্রুটি অভ্যন্তরীণ ত্রুটি। এর অর্থ হলো, অন্তর্নিহিত সিস্টেমের প্রত্যাশিত কিছু অপরিবর্তনীয়তা লঙ্ঘিত হয়েছে। এই ত্রুটি কোডটি গুরুতর ত্রুটির জন্য সংরক্ষিত এবং এটি অংশীদারের এপিআই সার্ভার বাস্তবায়নে একটি বাগ নির্দেশ করে।
৫০৩ পরিষেবা অনুপলব্ধ পরিষেবাটি অনুপলব্ধ। এটি সম্ভবত একটি সাময়িক অবস্থা, যা ব্যাকঅফ সহ পুনরায় চেষ্টা করে ঠিক করা যেতে পারে।
৫০৪ গেটওয়ে টাইমআউট অপারেশনটি সম্পন্ন হওয়ার আগেই সময়সীমা শেষ হয়ে গেছে। যেসব অপারেশন সিস্টেমের অবস্থা পরিবর্তন করে, সেগুলো সফলভাবে সম্পন্ন হলেও এই ত্রুটিটি প্রদর্শিত হতে পারে। উদাহরণস্বরূপ, সার্ভার থেকে একটি সফল প্রতিক্রিয়া আসতে এতটা দেরি হতে পারে যে সময়সীমা শেষ হয়ে গেছে।

মনে রাখবেন যে সমস্ত পূর্বশর্ত, অবৈধ আর্গুমেন্ট, বা খুঁজে না পাওয়ার ত্রুটির ক্ষেত্রে:

  • এপিআই-তে সংজ্ঞায়িত পদ্ধতি-নির্দিষ্ট প্রতিক্রিয়া বা ত্রুটির বার্তাগুলো ব্যবহার করা উচিত।
  • পদ্ধতি-নির্দিষ্ট কোডগুলিতে যেমন উল্লেখ করা আছে, সেই অনুযায়ী সঠিক http কোড ব্যবহার করা উচিত (উদাহরণস্বরূপ, TripOptionsErrorType দেখুন)।

এর ফলে এই ধরনের ত্রুটি সম্পর্কে আরও বিস্তারিত তথ্য প্রদান করা সম্ভব হয়। এই তথ্য নিম্নলিখিত ক্ষেত্রে ব্যবহার করা যেতে পারে:

  • ত্রুটিটি পুনরায় চেষ্টা করা যাবে কিনা তা নির্ধারণ করুন।
    • SEGMENT_KEY_NOT_FOUND পুনরায় চেষ্টা করা যাবে না।
  • পুরোনো তথ্য সংশোধন করুন
    • Unavailable.Reason.CANCELED নির্দেশ করে যে ট্রিপটি বাতিল করা উচিত (উল্লেখ্য যে এটি একটি সফল প্রতিক্রিয়ার অংশ)।
    • Unavailable.Reason.TEMPORARILY_UNAVAILABLE এবং সেইসাথে SEGMENT_KEY_NOT_FOUND , SUBOPTIMAL_ITINERARY , BOOKING_WINDOW_NOT_SUPPORTED ও TICKETING_PROHIBITED এরর কোডগুলো ক্যাশে থেকে আমাদের পূর্বে প্রাপ্ত যেকোনো মূল্য মুছে দেয়।
  • ব্যবহারকারীদের প্রাসঙ্গিক নির্দেশনা প্রদান করুন

TripOptionsError এ প্রদত্ত পদ্ধতি-নির্দিষ্ট ত্রুটির বর্তমান তালিকাটি একটি প্রাথমিক ধারণা মাত্র। যদি অতিরিক্ত ত্রুটির ধরনের প্রয়োজন হয়, তবে অনুগ্রহ করে Google Travel Transport টিমের সাথে যোগাযোগ করুন।

QPS (প্রতি সেকেন্ডে কোয়েরি)

পার্টনারদের ইনভেন্টরি এবং কতজন ব্যবহারকারী ক্যাশ করা ডেটা দেখেন বা বুকিংয়ের জন্য পার্টনারদের ওয়েবসাইটে ক্লিক করেন, তার উপর ভিত্তি করে গুগলের পাঠানো QPS-এর পরিমাণ পরিবর্তিত হতে পারে।

লেটেন্সি

অনুরোধগুলো ১০ সেকেন্ড পর টাইমআউট হয়ে যাবে। বিটা পার্টনার ইন্টিগ্রেশনের জন্য কোনো অতিরিক্ত ল্যাটেন্সি নির্দেশিকা থাকবে না। তবে, আমাদের পার্টনার ডেটা কোয়ালিটি গাইডলাইনসে পরবর্তী ল্যাটেন্সি SLO নির্ধারণ করা হবে।

মুদ্রা, কর এবং ফি

Google-কে পাঠানো সমস্ত মূল্যের সাথে সকল কর ও ফি অন্তর্ভুক্ত থাকতে হবে এবং তা একটি সমর্থিত মুদ্রায় উল্লেখ করতে হবে।

মুদ্রা

মূল্যের মুদ্রা currency_code ফিল্ড ব্যবহার করে নির্দিষ্ট করা হয়, যা অবশ্যই একটি বৈধ ISO 4217 মুদ্রা কোড হতে হবে।

উদাহরণ ১০.২৫ মার্কিন ডলার:

{
  "price": {
    "currency_code": "USD",
    "units": 10,
    "nanos": 250000000
  }
}

কর এবং ফি

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