Interceptor — یہ کیا ہے، OkHttp اور Alamofire انٹرسیپٹر کی اقسام

Interceptor کیا ہے؟

Interceptor ایک سافٹ ویئر جزو ہے جو HTTP کلائنٹ میں داخل کیا جاتا ہے تاکہ سرور کو بھیجنے سے پہلے درخواستوں اور ایپلیکیشن تک پہنچنے سے پہلے جوابات کو روکا اور تبدیل کیا جا سکے۔ موبائل ڈیولپمنٹ میں، انٹرسیپٹر کراس کٹنگ خدشات کو سنبھالتے ہیں: خودکار تصدیقی ٹوکن انجیکشن، وقت کی پیمائش کے ساتھ ٹریفک لاگنگ، عارضی نیٹ ورک خرابیوں پر دوبارہ کوشش، اور فوری ڈیٹا کمپریشن اور ڈیکرپشن۔ Interceptor آرکیٹیکچر Chain of Responsibility پیٹرن پر مبنی ہے — ہر انٹرسیپٹر درخواست کو تبدیل کر سکتا ہے، اسے انجام دے سکتا ہے یا حسب ضرورت جواب واپس کر کے زنجیر کو توڑ سکتا ہے۔

انٹرسیپٹر زنجیر کیسے کام کرتی ہے

OkHttp میں، انٹرسیپٹر ایک زنجیر بناتے ہیں۔ ہر Interceptor اصل درخواست کے ساتھ ایک Chain آبجیکٹ وصول کرتا ہے اور اگلے انٹرسیپٹر کو کنٹرول دینے کے لیے chain.proceed(request) کو کال کرتا ہے۔ جواب موصول ہونے کے بعد، انٹرسیپٹر Response کا تجزیہ کر سکتا ہے، اسے تبدیل کر سکتا ہے، خرابی پر درخواست دوبارہ کوشش کر سکتا ہے یا کیشنگ کے لیے حسب ضرورت جواب واپس کر سکتا ہے۔ OkHttpClient.Builder میں انٹرسیپٹر شامل کرنے کی ترتیب ان کے عمل درآمد کی ترتیب کا تعین کرتی ہے: پہلے شامل کردہ بھیجتے وقت پہلے اور وصول کرتے وقت آخر میں عمل کرتا ہے۔

OkHttp میں Interceptor: Application اور Network

OkHttp انٹرسیپٹر کو دو اقسام میں تقسیم کرتا ہے۔ Application Interceptor (addInterceptor) ایپلیکیشن کوڈ اور OkHttp کے درمیان عمل کرتا ہے: ایک chain.proceed() کال — ری ڈائریکٹ سے قطع نظر سرور کو ایک درخواست۔ Network Interceptor (addNetworkInterceptor) ہیڈر کی تشکیل اور کنیکشن کے بعد OkHttp کے اندر عمل کرتا ہے — یہ ہر ری ڈائریکٹ، دوبارہ کوشش یا تصدیقی کوشش پر چلتا ہے۔ یہ فرق کسی مخصوص کام کے لیے صحیح انٹرسیپٹر قسم کا انتخاب کرنے کے لیے اہم ہے۔

class LoggingInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        Log.d("HTTP", "${request.method} ${request.url}")

        val startTime = System.currentTimeMillis()
        val response = chain.proceed(request)
        val duration = System.currentTimeMillis() - startTime

        Log.d("HTTP", "${response.code} in ${duration}ms")
        return response
    }
}

val client = OkHttpClient.Builder()
    .addInterceptor(LoggingInterceptor())
    .addNetworkInterceptor(CacheInterceptor())
    .build()

LoggingInterceptor — ایک Application Interceptor جو طریقہ، URL، جوابی کوڈ اور عمل درآمد کا وقت لاگ کرتا ہے۔ addInterceptor() کے ذریعے اسے شامل کرنا ری ڈائریکٹ پر نقل کے بغیر صارف کی درخواست پر ایک لاگ کی ضمانت دیتا ہے۔ CacheInterceptor کو Network Interceptor کے طور پر شامل کیا جاتا ہے تاکہ سرور کے Cache-Control ہیڈر کو مدنظر رکھا جا سکے، جو HTTP درخواست بننے کے بعد صرف OkHttp کے اندر نظر آتے ہیں۔

عملی طور پر اقسام کے درمیان فرق

جب ایپلیکیشن درخواست کرتی ہے، تو سرور 302 یا 301 ری ڈائریکٹ کے ساتھ جواب دے سکتا ہے۔ Application Interceptor تمام ری ڈائریکٹ کے بعد صرف حتمی جواب دیکھتا ہے — اسے معلوم نہیں ہوتا کہ کتنی درمیانی درخواستیں کی گئیں۔ Network Interceptor درمیانی سمیت ہر درخواست اور جواب دیکھتا ہے۔ Square (2026) کے مطابق، Network Interceptor کنیکشن لیول پر کمپریسڈ ڈیٹا (gzip) بھی دیکھتا ہے، جبکہ Application Interceptor پہلے سے ڈیکمپریسڈ جواب وصول کرتا ہے۔ نیٹ ورک کالز کی اصل تعداد گننے کے لیے Network Interceptor استعمال کریں۔

Alamofire RequestInterceptor

Alamofire RequestInterceptor پروٹوکول فراہم کرتا ہے، جو دو پروٹوکول کو یکجا کرتا ہے: بھیجنے سے پہلے درخواست کو تبدیل کرنے کے لیے RequestAdapter اور خرابیوں پر دوبارہ کوشش کے لیے RequestRetrier۔ یہ علیحدگی موافقت (ہیڈر، ٹوکن شامل کرنا) کو دوبارہ کوشش کی پالیسی (ایکسپونینشل بیک آف، کوشش کی حد، خرابی کی قسم کی جانچ) کے ساتھ لچکدار طریقے سے یکجا کرنے کی اجازت دیتی ہے۔ RequestInterceptor ایک واحد ساخت یا کلاس کے ذریعے نافذ کیا جاتا ہے جو دونوں پروٹوکول کی تعمیل کرتی ہے۔

struct AuthInterceptor: RequestInterceptor {
    private let tokenProvider: TokenProvider

    func adapt(_ urlRequest: URLRequest,
                using state: Session.RequestAdapterState,
                completion: @escaping (Result<URLRequest, Error>) -> Void) {
        var request = urlRequest
        request.setValue("Bearer \(tokenProvider.token)",
                        forHTTPHeaderField: "Authorization")
        completion(.success(request))
    }

    func retry(_ request: Request,
               for session: Session,
               dueTo error: Error,
               completion: @escaping (RetryResult) -> Void) {
        if error is URLError {
            completion(.retryWithDelay(1))
        } else {
            completion(.doNotRetry)
        }
    }
}

AuthInterceptor Swift میں adapt کے ذریعے Bearer ٹوکن شامل کرتا ہے اور 1 سیکنڈ کی تاخیر کے ساتھ retry کے ذریعے URLError (نیٹ ورک کا نقصان، ٹائم آؤٹ) پر خود بخود درخواست دوبارہ کوشش کرتا ہے۔ موافقت اور دوبارہ کوشش کو الگ کرنا انہیں آزادانہ طور پر جانچنے کی اجازت دیتا ہے — آپ دوبارہ کوشش کی منطق کو متاثر کیے بغیر موافقت کے لیے یونٹ ٹیسٹ لکھ سکتے ہیں۔ Alamofire (2026) کے مطابق، RequestInterceptor iOS پروجیکٹس میں تصدیق کے انتظام کو مرکزی بنانے کا معیاری طریقہ ہے۔

انٹرسیپٹر کے استعمال کے کیسز

لاگنگ — سب سے عام استعمال کا کیس۔ Interceptor URL، طریقہ، ہیڈر، درخواست اور جواب کا باڈی اور عمل درآمد کا وقت ریکارڈ کرتا ہے۔ ڈیبگ بلڈز میں، یہ Charles Proxy اور Wireshark کی جگہ لے لیتا ہے؛ ریلیز بلڈز میں، یہ درخواست کے سیاق و سباق کے ساتھ کریش رپورٹس میں مدد کرتا ہے۔ OkHttp logging-interceptor لائبریری سے HttpLoggingInterceptor کو NONE، BASIC، HEADERS اور BODY لیولز کے ساتھ استعمال کرتا ہے۔ BODY لیول مکمل درخواست اور جواب کے باڈیز کو لاگ کرتا ہے — صرف ڈیبگ میں استعمال کریں۔

تصدیق اور ٹوکن ریفریش

جب رسائی ٹوکن ختم ہو جاتا ہے، Interceptor 401 جواب کو روکتا ہے، ٹوکن ریفریش API کو کال کرتا ہے اور نئے ٹوکن کے ساتھ اصل درخواست دوبارہ کوشش کرتا ہے۔ OkHttp میں، یہ Authenticator یا response.code جانچ کے ساتھ حسب ضرورت Interceptor کے ذریعے نافذ کیا جاتا ہے۔ Authenticator کو صرف جواب کے ہیڈر تک رسائی ہے، جبکہ Interceptor کو مکمل باڈی تک رسائی ہے۔ Alamofire میں — RequestRetrier کے ذریعے، ٹوکن ریفریش کے بعد .retry واپس کرتا ہے۔ OWASP (2026) کے مطابق، Interceptor کے ذریعے خودکار ٹوکن ریفریش اسناد کے رساؤ کے خطرے کو کم کرتا ہے۔

مشترکہ ہیڈر شامل کرنا

Content-Type، Accept-Language، User-Agent، Device-ID — وہ ہیڈر جو ہر درخواست میں درکار ہوتے ہیں۔ Interceptor انہیں مرکزی طور پر شامل کرتا ہے، بغیر ہر API طریقہ میں نقل کے۔ User-Agent ایپ اسٹارٹ اپ پر ایک بار تشکیل دیا جاتا ہے: «AppName/1.0 (Android 14; Pixel 8)»۔ Accept-Language ڈیوائس سسٹم زبان سے لیا جاتا ہے۔ Alamofire (2026) کے مطابق، Interceptor کے ذریعے مرکزی ہیڈر مینجمنٹ غلط ہیڈر کی خرابیوں کو 30% تک کم کرتا ہے۔

بہترین طرز عمل اور زنجیر کی ترتیب

OkHttp میں Interceptors شامل کرنے کی ترتیب پوری زنجیر کے رویے کا تعین کرتی ہے۔ پہلا شامل کردہ انٹرسیپٹر درخواست بھیجتے وقت پہلے اور جواب وصول کرتے وقت آخر میں عمل کرتا ہے۔ لاگنگ کے لیے، Interceptor کو پہلے شامل کریں — یہ دوسرے انٹرسیپٹرز کی تمام تبدیلیوں کے ساتھ حتمی درخواست دیکھے گا۔ کمپریشن کے لیے، اسے آخر میں شامل کریں تاکہ کمپریشن حتمی ڈیٹا پر لاگو ہو۔ تصدیق کے لیے، اسے دوبارہ کوشش سے پہلے شامل کریں تاکہ اگلی کوشش سے پہلے ٹوکن ریفریش ہو جائے۔

پروڈکشن بلڈز کے لیے سفارشات

ریلیز بلڈز میں، BuildConfig.DEBUG یا ڈیپنڈنسی انجیکشن کے ذریعے لاگنگ غیر فعال کریں۔ کیشنگ کے لیے addNetworkInterceptor استعمال کریں — Network Interceptor سرور کے Cache-Control ہیڈر دیکھتا ہے اور کیشنگ پالیسی کی صحیح تشریح کرتا ہے۔ تصدیق کے لیے، addInterceptor (Application) استعمال کریں — یہ تیسرے فریق کے ڈومینز پر ری ڈائریکٹ پر دوبارہ روک تھام کو روکتا ہے جہاں اجازت کے ہیڈر نہیں بھیجے جانے چاہئیں۔ okhttp-testing-support سے MockWebServer کا استعمال کرتے ہوئے ہر Interceptor کو الگ تھلگ جانچیں — یہ درخواستوں کو روکتا ہے اور پہلے سے تیار کردہ جوابات واپس کرتا ہے، جس سے آپ حقیقی سرور کے بغیر انٹرسیپٹر منطق کی تصدیق کر سکتے ہیں۔

Interceptor کی کارکردگی

ہر Interceptor درخواست کے وقت میں ایک چھوٹی تاخیر کا اضافہ کرتا ہے۔ 3-4 انٹرسیپٹر (لاگنگ، تصدیق، کمپریشن، کیشنگ) کی عام زنجیر میں، اوور ہیڈ فی درخواست 5 ملی سیکنڈ سے کم ہے۔ مسائل اس وقت پیدا ہوتے ہیں جب Interceptor بلاک کرنے والی کارروائیاں کرتا ہے: مطابقت پذیر ٹوکن ریفریش API کال، فائل میں بڑے لاگ لکھنا یا درخواست کے باڈی کو خفیہ کرنا۔ یہ تمام کارروائیاں غیر مطابقت پذیر ہونی چاہئیں یا بیک گراؤنڈ تھریڈ پر عمل میں لائی جائیں۔ Square (2026) کے مطابق، OkHttp Dispatcher تھریڈ پول میں Interceptors کو عمل میں لاتا ہے — ایک انٹرسیپٹر کو بلاک کرنا پوری زنجیر میں تاخیر کرتا ہے۔

• ترتیب اہم ہے — لاگنگ پہلے، دوبارہ کوشش سے پہلے تصدیق، کمپریشن آخر میں
• ڈیبگ بمقابلہ ریلیز — HttpLoggingInterceptor صرف ڈیبگ بلڈز میں
• علیحدگی — ہر Interceptor ایک کام سنبھالتا ہے (واحد ذمہ داری)
• غیر مطابقت پذیری — Interceptor OkHttp بیک گراؤنڈ تھریڈ پر چلتا ہے، UI کو بلاک نہیں کرتا