API HTTP API মানগুলির একটি সেট অনুসরণ করে এবং আরও শক্তিশালী ইন্টিগ্রেশনের সুবিধার্থে idempotency সমর্থন করে।
Google হোস্ট করা ইউআরএল
প্রতিটি Google-হোস্ট করা পদ্ধতির জন্য ডকুমেন্টেশন একটি বেস URL প্রদান করে, যার মধ্যে পদ্ধতির নাম এবং প্রধান সংস্করণ নম্বর রয়েছে। কলারের পেমেন্ট ইন্টিগ্রেটর অ্যাকাউন্ট আইডি শেষে যোগ করে সম্পূর্ণ URL তৈরি করা হয়। উদাহরণস্বরূপ, Google-হোস্টেড ইকো পদ্ধতির জন্য ডকুমেন্টেশন URLটি নির্দিষ্ট করে:
https://vgw.googleapis.com/secure-serving/gsp/v1/echo যদি কলারের পেমেন্ট ইন্টিগ্রেটর অ্যাকাউন্ট আইডি হয় INTEGRATOR_1 , তাহলে তারা সেটিকে ফর্মের URL-এর শেষে যোগ করবে:
https://vgw.googleapis.com/secure-serving/gsp/v1/echo/INTEGRATOR_1অংশীদার হোস্ট করা ইউআরএল
প্রতিটি অংশীদার হোস্ট করা API পদ্ধতির জন্য ডকুমেন্টেশন একটি বেস URL প্রদান করে, যার মধ্যে পদ্ধতির নাম এবং প্রধান সংস্করণ নম্বর রয়েছে। আপনার হোস্ট করা URLগুলিতে পেমেন্ট ইন্টিগ্রেটর অ্যাকাউন্ট আইডি ( PIAID ) অন্তর্ভুক্ত করা উচিত নয়৷
স্যান্ডবক্স এবং উত্পাদন পরিবেশ
Google স্যান্ডবক্স (উন্নয়ন এবং পরীক্ষার উদ্দেশ্যে) এবং উৎপাদন উভয় ক্ষেত্রেই স্ট্যান্ডার্ড পেমেন্ট এপিআই হোস্ট করে। Google স্যান্ডবক্স এনভায়রনমেন্টে অনুরোধের ফলে কোনো বাস্তব বিশ্ব আর্থিক দায় হয় না। স্যান্ডবক্স এবং উৎপাদন পরিবেশ সম্পূর্ণ আলাদা এবং কী বা লেনদেনের তথ্য শেয়ার করে না।
Google আশা করে যে আপনার স্যান্ডবক্স ধারাবাহিকভাবে উপলব্ধ থাকবে যেহেতু আমরা প্রথম পরিবর্তন এবং নতুন বৈশিষ্ট্যগুলি পরীক্ষা করতে স্যান্ডবক্স ব্যবহার করব৷
Google এর স্যান্ডবক্স বেস পাথ
https://vgw. sandbox.google .com/secure-serving/gsp/Google এর উৎপাদন ভিত্তি পথ
https://vgw.googleapis.com/secure-serving/gsp/এই নির্দেশিকা উৎপাদন শেষ পয়েন্ট ব্যবহার করবে.
বিষয়বস্তুর ধরন এবং এনকোডিং
PGP এনক্রিপশন ব্যবহার করে এমন মেসেজ পেলোড অবশ্যই কন্টেন্ট টাইপapplication/octet-stream; charset=utf-8 । rfc4648 §5 এ সংজ্ঞায়িত হিসাবে PGP রিকোয়েস্ট বডি অবশ্যই base64url এনকোডিং ব্যবহার করে পাঠাতে হবে।JWE এনক্রিপশন ব্যবহার করে এমন মেসেজ পেলোড অবশ্যই কন্টেন্ট টাইপ application/jose; charset=utf-8 । JWE/JWS দ্বারা সমর্থিত কমপ্যাক্ট সিরিয়ালাইজেশন বিকল্পটি চূড়ান্ত অনুরোধের অংশের জন্য এনকোডিং পরিচালনা করে।HTTP স্থিতি কোড
স্ট্যান্ডার্ড পেমেন্ট এপিআইগুলি সার্ভার দ্বারা প্রক্রিয়া করা যেতে পারে এমন সমস্ত অনুরোধের জন্য একটি HTTP 200 স্ট্যাটাস কোড ফেরত দেওয়ার জন্য ডিজাইন করা হয়েছে৷ এর মধ্যে ব্যবসা বা প্রয়োগের যুক্তির দৃষ্টিকোণ থেকে সফল এবং প্রত্যাখ্যান করা অনুরোধ উভয়ই অন্তর্ভুক্ত। যে অনুরোধগুলি প্রক্রিয়া করা যায় না সেগুলির ফলাফল একটি HTTP 200 স্ট্যাটাস কোড হওয়া উচিত নয় কারণ তারা Google এবং অংশীদারের মধ্যে একটি ত্রুটি উপস্থাপন করে৷ পরিবর্তে, API প্রতিক্রিয়া একটি ঐচ্ছিক ErrorResponse অবজেক্টের সাথে নীচের উপযুক্ত HTTP স্ট্যাটাস কোড ব্যবহার করা উচিত।
| HTTP ত্রুটি এবং কারণ | |
|---|---|
| 400 | BAD REQUESTক্লায়েন্ট একটি অবৈধ যুক্তি নির্দিষ্ট করেছে৷ অপারেশনটি প্রত্যাখ্যান করা হলে এটিও ফেরত দেওয়া যেতে পারে কারণ অপারেশনটি কার্যকর করার জন্য সিস্টেমটি প্রয়োজনীয় অবস্থায় নেই৷ সিস্টেমের অবস্থা স্পষ্টভাবে ঠিক না হওয়া পর্যন্ত অনুরোধের পুনঃপ্রয়াস সফল না হলে এটি ব্যবহার করুন। উদাহরণস্বরূপ, যদি একটি রিফান্ডের অনুরোধ ব্যর্থ হয় কারণ এটি এমন একটি ক্যাপচারের উল্লেখ করে যা বিদ্যমান নেই, তাহলে পুনরায় চেষ্টা করা সফল হবে না যতক্ষণ না ক্যাপচারটি ইন্টিগ্রেটর সিস্টেমে বিদ্যমান থাকে। |
| 401 | UNAUTHORIZEDঅনুরোধটির অপারেশনের জন্য বৈধ প্রমাণীকরণ শংসাপত্র নেই৷ উদাহরণস্বরূপ, অবৈধ স্বাক্ষর বা অজানা স্বাক্ষর 401 ফেরত দেওয়া উচিত। |
| 403 | FORBIDDEN / PERMISSION DENIEDকলার নির্দিষ্ট অপারেশন চালানোর অনুমতি নেই. |
| 404 | NOT FOUNDকিছু অনুরোধ করা সত্তা যেমন অর্থপ্রদান বা ব্যবহারকারী পাওয়া যায়নি। |
| 409 | CONFLICT / ABORTEDঅপারেশনটি স্থগিত করা হয়েছিল, সাধারণত সিকোয়েন্সার-চেক ব্যর্থতা, লেনদেন স্থগিত করা ইত্যাদির মতো একযোগে সমস্যার কারণে। |
| 412 | PRECONDITION FAILEDএই কোডটি এমন পরিস্থিতিতে ব্যবহার করা উচিত যেখানে একটি আইডেমপোটেন্সি কী বিভিন্ন প্যারামিটারের সাথে পুনরায় ব্যবহার করা হচ্ছে। |
| 429 | RESOURCE EXHAUSTED / TOO MANY REQUESTSকিছু সিস্টেম রিসোর্স শেষ হয়ে গেছে। |
| 499 | CANCELLEDঅপারেশন বাতিল করা হয়েছে (সাধারণত কলার দ্বারা)। |
| 500 | INTERNAL ERRORঅভ্যন্তরীণ ত্রুটি. এর অর্থ হল অন্তর্নিহিত সিস্টেমের দ্বারা প্রত্যাশিত কিছু পরিবর্তন ভেঙ্গে গেছে। |
| 501 | UNIMPLEMENTEDএই পরিষেবাতে অপারেশন বাস্তবায়িত, সমর্থিত বা সক্ষম করা হয় না। |
| 503 | UNAVAILABLEপরিষেবাটি বর্তমানে অনুপলব্ধ৷ এটি সম্ভবত একটি ক্ষণস্থায়ী অবস্থা এবং পুনরায় চেষ্টা করে সংশোধন করা যেতে পারে। |
| 504 | GATEWAY TIMEOUT / DEADLINE EXCEEDEDঅপারেশন শেষ হওয়ার আগেই সময়সীমা শেষ হয়ে গেছে। সিস্টেমের অবস্থা পরিবর্তন করে এমন অপারেশনগুলির জন্য, অপারেশনটি সফলভাবে সম্পন্ন হলেও এই ত্রুটিটি ফেরত দেওয়া হতে পারে। উদাহরণস্বরূপ, একটি সার্ভার থেকে একটি সফল প্রতিক্রিয়ার সময়সীমা শেষ হওয়ার জন্য যথেষ্ট দেরি হতে পারে। |
অদম্যতা অনুরোধ
রিকোয়েস্ট আইডেমপোটেন্সি হল একটি কেন্দ্রীয় কৌশল যা স্ট্যান্ডার্ড পেমেন্ট এপিআই-এ ব্যবহৃত হয় যা নিশ্চিত করতে ব্যবহৃত হয় যে Google এবং অংশীদারদের মধ্যে সিস্টেম ইন্টারঅ্যাকশন শক্তিশালী এবং ত্রুটি সহনশীল। অদম্য অনুরোধগুলি এমন অনুরোধ যা সম্ভাব্য একাধিকবার পাঠানো যেতে পারে তবে একটি একক অনুরোধের মতো একই প্রভাব রয়েছে। এই কৌশলটি আমাদের সিস্টেমগুলিকে সম্পদের অবস্থার উপর একত্রিত হওয়ার অনুমতি দিয়ে নিরাপদে পুনঃপ্রচেষ্টা করে সিস্টেমগুলির মধ্যে চূড়ান্ত সামঞ্জস্যের সুবিধা দেয়৷
আমাদের এপিআই এর জন্য অদম্যতা লাভ করে:
- সমস্ত ক্রিয়াগুলিকে সহজেই সনাক্তযোগ্য এবং নিরীক্ষণযোগ্য করে পুনর্মিলন সমস্যাগুলি হ্রাস করুন।
- একই ক্লায়েন্ট থেকে একাধিক অভিন্ন অনুরোধের ফলে একটি ভিন্ন চূড়ান্ত অবস্থা না হয় তা নিশ্চিত করে রেসের অবস্থা প্রতিরোধ করুন।
- অনুরোধগুলিকে বিচ্ছিন্নভাবে বোঝার অনুমতি দিয়ে, ডেটা ধরে রাখার কারণে সার্ভারের লোড সরিয়ে উন্নত কর্মক্ষমতা এবং থ্রুপুট করার অনুমতি দিয়ে অবস্থাকে ছোট করুন।
- অনুরোধটি পুনরায় চেষ্টা করা হলে তা নির্দেশ করার জন্য অতিরিক্ত ক্ষেত্রের প্রয়োজন এড়ান
উদাহরণ
উদাহরণ 1: প্রতিক্রিয়া পাওয়ার আগেই সংযোগ হারিয়ে গেছে
দৃশ্যকল্প:
- গুগল ইন্টিগ্রেটরের কাছে একটি অনুরোধ পাঠায়।
- ইন্টিগ্রেটর সার্ভার এই অনুরোধটি গ্রহণ করে এবং এটি সফলভাবে প্রক্রিয়া করে।
- ধাপ #2-এ প্রতিক্রিয়া পাওয়ার আগে Google-এর সার্ভার ক্ষমতা হারিয়ে ফেলে।
- Google এর সার্ভার পাওয়ার পুনরুদ্ধার করা হয়েছে এবং একই অনুরোধটি সমস্ত একই প্যারামিটারের সাথে পাঠানো হয়েছে (একই অনুরোধ আইডি এবং অনুরোধের বিবরণ কিন্তু আপডেট করা
requestTimestamp) ইন্টিগ্রেটরের সার্ভারে।
ফলাফল:
এই ক্ষেত্রে ইন্টিগ্রেটর সার্ভারকে অবশ্যই পদক্ষেপ # 2 এ দেওয়া একই উত্তরের সাথে উত্তর দিতে হবে কারণ responseTimestamp ব্যতীত সমস্ত পরামিতি একই। পার্শ্ব-প্রতিক্রিয়া শুধুমাত্র একবার ঘটে, ধাপ 2 এ। ধাপ 4 এর কোন পার্শ্ব-প্রতিক্রিয়া নেই।
উদাহরণ 2: রক্ষণাবেক্ষণের অধীনে একটি সার্ভারে অনুরোধ পাঠানো হয়েছে
দৃশ্যকল্প:
- ইন্টিগ্রেটর সার্ভারের ডাটাবেস রক্ষণাবেক্ষণের জন্য ডাউন।
- গুগল ইন্টিগ্রেটরের কাছে একটি অনুরোধ পাঠায়।
- ইন্টিগ্রেটর সঠিকভাবে
UNAVAILABLEস্থিতি কোড প্রদান করে। - Google এর সার্ভার প্রতিক্রিয়া গ্রহণ করে এবং পুনরায় চেষ্টা করার সময় নির্ধারণ করে।
- ইন্টিগ্রেটর সার্ভারের ডাটাবেস অনলাইনে ফিরে আসে।
- Google ধাপ #2 থেকে অনুরোধটি পুনরায় পাঠায় (একই অনুরোধ আইডি এবং অনুরোধের বিশদ বিবরণ কিন্তু আপডেট করা
requestTimestamp)। মনে রাখবেন যে উভয় অনুরোধের জন্য অনুরোধ আইডি একই হওয়া উচিত। - ইন্টিগ্রেটর সার্ভার অনুরোধ গ্রহণ করে এবং সম্পূর্ণ প্রতিক্রিয়া সহ একটি ওকে স্ট্যাটাস কোড ফেরত দেয়।
ফলাফল:
এই ক্ষেত্রে ইন্টিগ্রেটর সার্ভারকে অবশ্যই #7 ধাপে অনুরোধটি প্রক্রিয়া করতে হবে এবং HTTP 503 ( UNAVAILABLE ) ফেরত দেবে না। পরিবর্তে, ইন্টিগ্রেটর সার্ভারের অনুরোধটি সম্পূর্ণরূপে প্রক্রিয়া করা উচিত এবং উপযুক্ত বার্তাপ্রেরণের সাথে ঠিক আছে। মনে রাখবেন যে সিস্টেমটি UNAVAILABLE থাকাকালীন Google ধাপ #2 এর মতো বারবার অনুরোধ করতে পারে। প্রতিটি অনুরোধের ফলে ধাপ #3 এর মতো একটি বার্তা পাওয়া উচিত। অবশেষে, ধাপ #6 এবং ধাপ #7 ঘটবে।
উদাহরণ 3: পুনরুদ্ধার ত্রুটির কারণে পুনরায় চেষ্টা করা বার্তাটি প্রাথমিক বার্তার সাথে মেলে না
দৃশ্যকল্প:
- গুগল ইন্টিগ্রেটরের কাছে একটি অনুরোধ পাঠায়।
- ইন্টিগ্রেটর সার্ভার এই অনুরোধটি গ্রহণ করে এবং এটি সফলভাবে প্রক্রিয়া করে।
- ধাপ #2-এ প্রতিক্রিয়া পাওয়ার আগে Google-এর সার্ভার ক্ষমতা হারিয়ে ফেলে।
- Google এর সার্ভার পাওয়ার পুনরুদ্ধার করা হয়েছে এবং একই অনুরোধ পাঠানোর চেষ্টা করছে কিন্তু দুর্ভাগ্যবশত কিছু প্যারামিটার ভিন্ন।
ফলাফল:
এই ক্ষেত্রে ইন্টিগ্রেটর সার্ভারের একটি HTTP 412 ( PRECONDITION FAILED ) ত্রুটি কোডের সাথে উত্তর দেওয়া উচিত যা Google কে বোঝায় যে এই সিস্টেমে একটি ত্রুটি রয়েছে৷