Conditional GET: এটি কী, শর্তসাপেক্ষ অনুরোধের প্রক্রিয়া

HTTP-তে Conditional GET কী?

Conditional GET হল একটি GET অনুরোধ যা এক বা একাধিক শর্তসাপেক্ষ হেডার অন্তর্ভুক্ত করে, যার ভিত্তিতে সার্ভার সিদ্ধান্ত নেয় সম্পূর্ণ প্রতিক্রিয়া ফেরত দেবে নাকি শুধুমাত্র 304 Not Modified স্থিতি। মূল লক্ষ্য হল প্রতিক্রিয়া বডি স্থানান্তর এড়ানো যদি রিসোর্স শেষ অনুরোধের পর থেকে পরিবর্তিত না হয়। এটি RFC 7232-এ সংজ্ঞায়িত একটি মৌলিক HTTP ক্যাশিং প্রক্রিয়া।

মোবাইল অ্যাপ্লিকেশনের জন্য, Conditional GET নেটওয়ার্ক ট্রাফিক অপ্টিমাইজ করার সবচেয়ে কার্যকর উপায়গুলির মধ্যে একটি। একটি সাধারণ পরিস্থিতি: অ্যাপ খোলার সময়, ক্লায়েন্ট ফিড, প্রোফাইল এবং সেটিংস লোড করতে শর্তসাপেক্ষ GET অনুরোধের একটি সিরিজ পাঠায়। যদি ডেটা পরিবর্তিত না হয়, অ্যাপ 304 পায় এবং স্থানীয় কপি ব্যবহার করে। এটি সেকেন্ডের পরিবর্তে মিলিসেকেন্ড সময় নেয় এবং মোবাইল ডেটা ব্যবহার করে না।

Google Web Fundamentals (2025) অনুসারে, মোবাইল অ্যাপ্লিকেশনে শর্তসাপেক্ষ GET অনুরোধ বাস্তবায়ন করলে পুনরাবৃত্তি ভিজিটের জন্য গড় লোড সময় 40–60% কমে যায় এবং বিরল আপডেটের পৃষ্ঠাগুলির জন্য ট্রাফিক ব্যবহার 70–90% হ্রাস পায়। প্রভাব বিশেষ করে ধীর সংযোগে (3G, Edge) লক্ষণীয়, যেখানে প্রতিটি বাইট গুরুত্বপূর্ণ।

শর্তসাপেক্ষ GET অনুরোধ কীভাবে কাজ করে

প্রক্রিয়াটি তিনটি ধাপে ঘটে। প্রথম — ক্লায়েন্ট একটি সাধারণ GET অনুরোধ পাঠায়, সার্ভার ক্যাশিং হেডার (ETag, Last-Modified) সহ রিসোর্স ফেরত দেয়। দ্বিতীয় — ক্লায়েন্ট রিসোর্স এবং এর যাচাইকারীকে স্থানীয়ভাবে সংরক্ষণ করে। তৃতীয় — পুনরাবৃত্তি অনুরোধে, ক্লায়েন্ট If-None-Match (ETag-এর জন্য) এবং/অথবা If-Modified-Since (Last-Modified-এর জন্য) সহ GET পাঠায়। সার্ভার যাচাইকারী পরীক্ষা করে এবং রিসোর্স পরিবর্তিত না হলে 304, অথবা নতুন ডেটা সহ 200 প্রতিক্রিয়া জানায়।

সার্ভার উভয় হেডার উপস্থিত থাকলে ETag-কে Last-Modified-এর উপর অগ্রাধিকার দেয়। কারণ ETag আরও সঠিক যাচাইকরণ প্রদান করে — বিষয়বস্তু হ্যাশ যে কোনো পরিবর্তনের সাথে পরিবর্তিত হয়, যেখানে Last-Modified-এর এক সেকেন্ডের রেজোলিউশন রয়েছে। যদি ETag মেলে, সার্ভার Last-Modified পরীক্ষা না করেই অবিলম্বে 304 ফেরত দেয়।

অনুরোধ ক্রমে সম্পূর্ণ Conditional GET চক্রের উদাহরণ:

// ধাপ 1: প্রথম অনুরোধ — ডেটা ও ETag পান
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// ধাপ 2: অনুরোধ পুনরাবৃত্তি করুন — If-None-Match সহ
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// প্রতিক্রিয়া বড়ি অনুপস্থিত — স্থানীয় কপি ব্যবহার করুন

দ্বিতীয় অনুরোধে, সার্ভার If-None-Match থেকে ETag বর্তমান রিসোর্স হ্যাশের সাথে তুলনা করে। যদি মেলে, এটি বডি ছাড়া 304 ফেরত দেয় — ক্লায়েন্ট ক্যাশেড ডেটা ব্যবহার করতে থাকে। এটি Conditional GET-এর সারমর্ম: ন্যূনতম ট্রাফিকের সাথে সর্বাধিক ডেটা সাম্প্রতিকতা।

Conditional GET বনাম সাধারণ GET

সাধারণ GET অনুরোধ সর্বদা বডি সহ সম্পূর্ণ 200 OK প্রতিক্রিয়া ফেরত দেয়। এমনকি যদি রিসোর্স পরিবর্তিত না হয়, সার্ভার আবার সমস্ত ডেটা স্থানান্তর করে। এটি ছোট রিসোর্স বা বিরল অনুরোধের জন্য গ্রহণযোগ্য, কিন্তু প্রতিটি লঞ্চে শত শত অনুরোধ সহ মোবাইল অ্যাপ্লিকেশনের জন্য, এই পদ্ধতি অতিরিক্ত ট্রাফিক এবং ব্যাটারি খরচের দিকে নিয়ে যায়।

Conditional GET হেডার আকারে ওভারহেড যোগ করে (সাধারণত 50–200 বাইট প্রতি অনুরোধ) কিন্তু 304 প্রতিক্রিয়ার সাথে কিলোবাইট এবং মেগাবাইট সাশ্রয় করে। রিসোর্স যত বড়, শর্তসাপেক্ষ অনুরোধ তত বেশি লাভজনক। 10 KB এবং তার উপরের ছবি, ডেটা তালিকা এবং JSON ডকুমেন্টের জন্য, Conditional GET প্রথম পুনরাবৃত্তি অনুরোধ থেকেই লাভজনক হয়।

দুটি পদ্ধতির তুলনামূলক বৈশিষ্ট্য:

Kotlin-এ বাস্তবায়নের উদাহরণ

আসুন একটি সম্পূর্ণ বাস্তবায়ন দেখি OkHttp এবং Room ব্যবহার করে Kotlin-এ Conditional GET-এর, ETag সংরক্ষণের জন্য। একটি টাস্ক তালিকা অ্যাপ্লিকেশন সার্ভার থেকে টাস্ক লোড করে এবং ট্রাফিক কমাতে শর্তসাপেক্ষ অনুরোধ ব্যবহার করে। ETag সেশনগুলির মধ্যে ধরে রাখতে স্থানীয় ডেটাবেসে সংরক্ষণ করা হয়।

Kotlin-এ Conditional GET সহ রিপোজিটরি:

class TaskRepository(
    private val api: TaskApi,
    private val etagDao: EtagDao
) {
    suspend fun getTasks(): List<Task> {
        val savedEtag = etagDao.getEtag("tasks")

        val response = api.fetchTasks(
            ifNoneMatch = savedEtag
        )

        return when (response.code()) {
            304 -> taskDao.getAll() // স্থানীয় ক্যাশে থেকে
            200 -> {
                response.header("ETag")?.let {
                    etagDao.saveEtag("tasks", it)
                }
                val tasks = response.body() ?: emptyList()
                taskDao.replaceAll(tasks)
                tasks
            }
            else -> throw Exception(
                "Sync failed: ${response.code()}")
        }
    }
}

TaskRepository প্রতিক্রিয়া কোড পরীক্ষা করে: 304 মানে কোনো পরিবর্তন নেই, এবং ডেটা স্থানীয় Room ক্যাশে থেকে ফেরত দেওয়া হয়। 200-এ, একটি নতুন ETag সংরক্ষণ করা হয় এবং টাস্কগুলি স্থানীয় ডেটাবেসে আপডেট করা হয়। REST API সিঙ্ক্রোনাইজেশন সহ মোবাইল অ্যাপ্লিকেশনের জন্য এই প্যাটার্নটি একটি মানদণ্ড।

মোবাইল ডেভেলপমেন্টে Conditional GET-এর ব্যবহার

Conditional GET ব্যাপকভাবে ব্যবহৃত হয় মোবাইল অ্যাপ্লিকেশনে ডেটা সিঙ্ক্রোনাইজেশন অপ্টিমাইজেশনের জন্য। প্রধান পরিস্থিতি: নিউজ ফিড লোড করা (Twitter, Instagram পর্যায়ক্রমে If-None-Match সহ API পোল করে), ব্যবহারকারী প্রোফাইল আপডেট করা, নোটিফিকেশন তালিকা লোড করা এবং টাস্ক সিঙ্ক করা। প্রতিটি ক্ষেত্রে, অ্যাপ ডেটা পুনরায় ডাউনলোড না করেই তার সাম্প্রতিকতা পরীক্ষা করতে পারে।

অফলাইন-প্রথম অ্যাপ্লিকেশন এর জন্য, Conditional GET সিঙ্ক্রোনাইজেশনের প্রথম ধাপ হিসাবে কাজ করে। অ্যাপ প্রথমে শেষ সিঙ্কের পর থেকে স্থানীয়ভাবে পরিবর্তিত সমস্ত রিসোর্সের জন্য শর্তসাপেক্ষ GET অনুরোধ পাঠায়। 304 সহ রিসোর্সগুলির ডাউনলোডের প্রয়োজন নেই। এর পরে, অ্যাপ স্থানীয় পরিবর্তনের জন্য PUT/POST পাঠায়। এই দ্বি-পর্যায় পদ্ধতি ন্যূনতম ট্রাফিক খরচ নিশ্চিত করে।

দ্বন্দ্ব সমাধান এর সংমিশ্রণে, Conditional GET কার্যকর দ্বন্দ্ব সনাক্তকরণের অনুমতি দেয়। যদি ক্লায়েন্ট নতুন ডেটা সহ 200 পায় (রিসোর্স পরিবর্তিত হয়েছে) কিন্তু অপ্রেরিত স্থানীয় পরিবর্তন থাকে — একটি দ্বন্দ্ব নথিভুক্ত হয়। ক্লায়েন্ট LWW প্রয়োগ করতে পারে (স্থানীয় পরিবর্তন হারিয়ে যায়) বা স্থানীয় এবং দূরবর্তী পরিবর্তনগুলি একত্রিত করতে মার্জ কৌশল শুরু করতে পারে। Meta Engineering Blog (2025) অনুসারে, Messenger-এ Conditional GET বাস্তবায়ন গড় সিঙ্ক ট্রাফিক 73% কমিয়েছে।