অনুমোদন
Google Photos API-এর সমস্ত অনুরোধ একজন প্রমাণীকৃত ব্যবহারকারীর দ্বারা অনুমোদিত হতে হবে।
OAuth 2.0-এর অনুমোদন প্রক্রিয়ার বিশদ বিবরণ আপনি কি ধরনের আবেদন লিখছেন তার উপর নির্ভর করে কিছুটা পরিবর্তিত হয়। নিম্নলিখিত সাধারণ প্রক্রিয়া সব ধরনের আবেদনের ক্ষেত্রে প্রযোজ্য:
- নিম্নলিখিতগুলি করে অনুমোদন প্রক্রিয়ার জন্য প্রস্তুত করুন:
- Google API কনসোল ব্যবহার করে আপনার অ্যাপ্লিকেশন নিবন্ধন করুন৷
- ফটো API সক্রিয় করুন এবং OAuth বিশদ যেমন একটি ক্লায়েন্ট আইডি এবং একটি ক্লায়েন্ট গোপনীয়তা পুনরুদ্ধার করুন৷ আরও তথ্যের জন্য, শুরু করুন দেখুন।
- ব্যবহারকারীর ডেটা অ্যাক্সেস করতে, অ্যাপ্লিকেশনটি অ্যাক্সেসের একটি নির্দিষ্ট সুযোগের জন্য Google এর কাছে একটি অনুরোধ করে।
- Google ব্যবহারকারীর কাছে একটি সম্মতি স্ক্রিন প্রদর্শন করে যা তাদের কিছু ডেটা অনুরোধ করার জন্য অ্যাপ্লিকেশনটিকে অনুমোদন করতে বলে।
- ব্যবহারকারী অনুমোদন করলে, Google অ্যাপটিকে একটি অ্যাক্সেস টোকেন প্রদান করে যা একটি সংক্ষিপ্ত সময়ের পরে মেয়াদ শেষ হয়ে যায়।
- অ্যাপ্লিকেশনটি ব্যবহারকারীর ডেটার জন্য অনুরোধ করে, অনুরোধে অ্যাক্সেস টোকেন সংযুক্ত করে।
- যদি Google নির্ধারণ করে যে অনুরোধ এবং টোকেন বৈধ, এটি অনুরোধ করা ডেটা ফেরত দেয়।
আপনার আবেদনের জন্য কোন স্কোপগুলি উপযুক্ত তা নির্ধারণ করতে, অনুমোদনের সুযোগগুলি দেখুন।
কিছু অ্যাপ্লিকেশন প্রকারের প্রক্রিয়ায় অতিরিক্ত পদক্ষেপ অন্তর্ভুক্ত থাকে, যেমন নতুন অ্যাক্সেস টোকেনগুলি অর্জন করতে রিফ্রেশ টোকেন ব্যবহার করা। বিভিন্ন ধরনের অ্যাপ্লিকেশানের জন্য প্রবাহ সম্পর্কে বিস্তারিত তথ্যের জন্য, Google API অ্যাক্সেস করতে OAuth 2.0 ব্যবহার করা দেখুন।
ক্যাশিং
ডেটা তাজা রাখুন।
পারফরম্যান্সের কারণে আপনার যদি সাময়িকভাবে মিডিয়া (যেমন থাম্বনেইল, ফটো বা ভিডিও) সংরক্ষণ করার প্রয়োজন হয়, তাহলে আমাদের ব্যবহারের নির্দেশিকা অনুযায়ী 60 মিনিটের বেশি সময় ধরে এটিকে ক্যাশে করবেন না।
আপনি baseUrls সঞ্চয় করবেন না, যা প্রায় 60 মিনিটের পরে মেয়াদ শেষ হয়ে যায়।
মিডিয়া আইটেম আইডি এবং অ্যালবাম আইডি যেগুলি ব্যবহারকারীর লাইব্রেরির সামগ্রীকে অনন্যভাবে সনাক্ত করে সেগুলি ক্যাশিং সীমাবদ্ধতা থেকে অব্যাহতিপ্রাপ্ত৷ আপনি এই আইডিগুলি অনির্দিষ্টকালের জন্য সংরক্ষণ করতে পারেন (আপনার অ্যাপ্লিকেশনের গোপনীয়তা নীতি সাপেক্ষে)। মিডিয়া আইটেম আইডি এবং অ্যালবাম আইডি ব্যবহার করুন অ্যাক্সেসযোগ্য ইউআরএল এবং ডেটা পুনরুদ্ধার করার জন্য উপযুক্ত শেষ পয়েন্ট ব্যবহার করে। আরও তথ্যের জন্য, একটি মিডিয়া আইটেম বা তালিকা অ্যালবাম পান দেখুন।
আপনার কাছে রিফ্রেশ করার জন্য অনেকগুলি মিডিয়া আইটেম থাকলে, মিডিয়া আইটেমগুলি ফেরত দেয় এমন অনুসন্ধান পরামিতিগুলি সংরক্ষণ করা এবং ডেটা পুনরায় লোড করার জন্য ক্যোয়ারী পুনরায় জমা দেওয়া আরও কার্যকর হতে পারে৷
SSL অ্যাক্সেস
নিম্নলিখিত URL ব্যবহার করে সমস্ত ফটো API-এর ওয়েব পরিষেবার অনুরোধের জন্য HTTPS প্রয়োজন:
https://photoslibrary.googleapis.com/v1/service/output?parameters
HTTP এর মাধ্যমে করা অনুরোধ প্রত্যাখ্যান করা হয়।
ত্রুটি হ্যান্ডলিং
এপিআই থেকে প্রত্যাবর্তিত ত্রুটিগুলি কীভাবে পরিচালনা করবেন সে সম্পর্কিত তথ্যের জন্য, ক্লাউড এপিআই হ্যান্ডলিং ত্রুটিগুলি দেখুন।
ব্যর্থ অনুরোধ পুনরায় চেষ্টা করা হচ্ছে
ক্লায়েন্টদের এক্সপোনেনশিয়াল ব্যাকঅফের বর্ণনা অনুযায়ী 5xx ত্রুটির উপর পুনরায় চেষ্টা করা উচিত। অন্যথায় নথিভুক্ত না হলে ন্যূনতম বিলম্ব 1 s হওয়া উচিত।
429 ত্রুটির জন্য, ক্লায়েন্ট সর্বনিম্ন 30s বিলম্বের সাথে পুনরায় চেষ্টা করতে পারে। অন্য সব ত্রুটির জন্য, পুনরায় চেষ্টা প্রযোজ্য নাও হতে পারে। নিশ্চিত করুন যে আপনার অনুরোধ অদম্য এবং নির্দেশিকা জন্য ত্রুটি বার্তা দেখুন.
সূচকীয় ব্যাকঅফ
বিরল ক্ষেত্রে, আপনার অনুরোধ পরিবেশন করতে কিছু ভুল হতে পারে। আপনি একটি 4XX বা 5XX HTTP প্রতিক্রিয়া কোড পেতে পারেন, অথবা আপনার ক্লায়েন্ট এবং Google এর সার্ভারের মধ্যে কোথাও TCP সংযোগ ব্যর্থ হতে পারে। প্রায়শই, অনুরোধটি পুনরায় চেষ্টা করা সার্থক। আসল ব্যর্থ হলে ফলো-আপ অনুরোধ সফল হতে পারে। যাইহোক, লুপ না করা গুরুত্বপূর্ণ, বারবার Google এর সার্ভারে অনুরোধ করা। এই লুপিং আচরণ আপনার ক্লায়েন্ট এবং Google এর মধ্যে নেটওয়ার্ককে ওভারলোড করতে পারে এবং অনেক পক্ষের জন্য সমস্যা সৃষ্টি করতে পারে।
একটি ভাল পদ্ধতি হল প্রচেষ্টার মধ্যে ক্রমবর্ধমান বিলম্বের সাথে পুনরায় চেষ্টা করা। সাধারণত, বিলম্ব প্রতিটি প্রচেষ্টার সাথে একটি গুণক ফ্যাক্টর দ্বারা বৃদ্ধি করা হয়, একটি পদ্ধতি যা এক্সপোনেনশিয়াল ব্যাকঅফ নামে পরিচিত।
আপনার সতর্কতা অবলম্বন করা উচিত যে অ্যাপ্লিকেশন কল চেইনে উচ্চতর কোড পুনরায় চেষ্টা না করা যা দ্রুত ধারাবাহিকভাবে অনুরোধের দিকে নিয়ে যায়।
Google API-এর ভদ্র ব্যবহার
খারাপভাবে ডিজাইন করা API ক্লায়েন্টরা ইন্টারনেট এবং Google এর সার্ভার উভয় ক্ষেত্রেই প্রয়োজনের চেয়ে বেশি লোড রাখতে পারে। এই বিভাগে API-এর ক্লায়েন্টদের জন্য কিছু সেরা অনুশীলন রয়েছে। এই সর্বোত্তম অনুশীলনগুলি অনুসরণ করা আপনাকে API গুলির অসাবধানতাবশত অপব্যবহারের জন্য আপনার অ্যাপ্লিকেশন ব্লক হওয়া এড়াতে সহায়তা করতে পারে।
সিঙ্ক্রোনাইজ করা অনুরোধ
Google-এর এপিআই-এ বিপুল সংখ্যক সিঙ্ক্রোনাইজ করা অনুরোধগুলি Google-এর পরিকাঠামোতে ডিস্ট্রিবিউটেড ডিনায়েল অফ সার্ভিস (DDoS) আক্রমণের মতো দেখতে পারে এবং সেই অনুযায়ী আচরণ করা হবে। এটি এড়াতে, আপনাকে নিশ্চিত করতে হবে যে API অনুরোধগুলি ক্লায়েন্টদের মধ্যে সিঙ্ক্রোনাইজ করা হয়নি।
উদাহরণস্বরূপ, একটি অ্যাপ্লিকেশন বিবেচনা করুন যা বর্তমান সময় অঞ্চলে সময় প্রদর্শন করে। এই অ্যাপ্লিকেশনটি সম্ভবত ক্লায়েন্ট অপারেটিং সিস্টেমে একটি অ্যালার্ম সেট করবে যা মিনিটের শুরুতে এটিকে জাগিয়ে দেবে যাতে প্রদর্শিত সময় আপডেট করা যায়। অ্যালার্মের সাথে যুক্ত প্রক্রিয়াকরণের অংশ হিসাবে অ্যাপ্লিকেশনটির কোনো API কল করা উচিত নয়।
একটি নির্দিষ্ট অ্যালার্মের প্রতিক্রিয়া হিসাবে API কল করা খারাপ কারণ এর ফলে API কলগুলি সময়ের সাথে সমানভাবে বিতরণ না করে এমনকি বিভিন্ন ডিভাইসের মধ্যেও মিনিটের শুরুতে সিঙ্ক্রোনাইজ করা হয়। একটি খারাপভাবে ডিজাইন করা অ্যাপ্লিকেশন এটি করে প্রতি মিনিটের শুরুতে স্বাভাবিক মাত্রার ষাট গুণে ট্রাফিকের স্পাইক তৈরি করে।
পরিবর্তে, একটি সম্ভাব্য ভাল ডিজাইন হল একটি এলোমেলোভাবে নির্বাচিত সময়ে একটি দ্বিতীয় অ্যালার্ম সেট করা। যখন এই দ্বিতীয় অ্যালার্মটি ফায়ার হয়, তখন অ্যাপ্লিকেশনটি প্রয়োজনীয় যে কোনো API-কে কল করে এবং ফলাফল সংরক্ষণ করে। মিনিটের শুরুতে এর প্রদর্শন আপডেট করতে, অ্যাপ্লিকেশনটি আবার API কল করার পরিবর্তে পূর্বে সংরক্ষিত ফলাফল ব্যবহার করে। এই পদ্ধতির সাথে, API কলগুলি সময়ের সাথে সমানভাবে ছড়িয়ে পড়ে। আরও, যখন ডিসপ্লে আপডেট করা হচ্ছে তখন API কল রেন্ডারিং করতে দেরি করে না।
মিনিটের শুরুর পাশাপাশি, অন্যান্য সাধারণ সিঙ্ক্রোনাইজেশন সময়গুলিকে লক্ষ্য করা উচিত নয় যাতে লক্ষ্য করা না যায় এক ঘন্টার শুরুতে এবং মধ্যরাতে প্রতিটি দিনের শুরুতে।