Retrofit: یہ کیا ہے، Android HTTP کلائنٹ کی خصوصیات

Retrofit کیا ہے؟

Retrofit Android پلیٹ فارم پر REST API کے ساتھ ٹائپ شدہ تعامل کے لیے ایک لائبریری ہے، جسے Square نے تیار کیا ہے۔ یہ اینوٹیشنز کے ساتھ Java یا Kotlin انٹرفیس کے ذریعے HTTP درخواستوں کو بیان کرنے کا ایک اعلانیہ طریقہ فراہم کرتی ہے، جو دستی JSON تجزیہ اور HTTP کنکشن مینجمنٹ کی ضرورت کو مکمل طور پر ختم کرتی ہے۔

یہ لائبریری 2013 میں AsyncTask اور HttpURLConnection جیسے بوجھل حل کے متبادل کے طور پر سامنے آئی۔ 2025 تک، Retrofit اپنی سادگی اور ٹائپ سیفٹی کی وجہ سے Android ایپس میں نیٹ ورک کمیونیکیشن کا حقیقی معیار بنا ہوا ہے۔ JetBrains Developer Ecosystem 2024 سروے کے مطابق، 65% سے زیادہ Android ڈویلپر تجارتی منصوبوں میں Retrofit استعمال کرتے ہیں۔

Retrofit کا متبادلات سے بنیادی فرق اعلانیہ نقطہ نظر ہے: ڈویلپر بیان کرتا ہے کہ کیا کرنا ہے (کون سا اینڈپوائنٹ کال کرنا ہے، کون سے پیرامیٹرز منتقل کرنے ہیں) بجائے اس کے کہ کیسے کرنا ہے (کنکشن کیسے کھولیں، InputStream کیسے پڑھیں، JSON کیسے پارس کریں)۔ یہ HttpURLConnection کے دستی استعمال کے مقابلے میں boilerplate کوڈ کو 60–70% تک کم کرتا ہے۔

Retrofit کیسے کام کرتا ہے

کام کرنے کا اصول Retrofit Java ڈائنامک پراکسیز پر مبنی ہے۔ جب ڈویلپر اینوٹیٹڈ انٹرفیس کے کسی طریقے کو کال کرتا ہے، تو Retrofit Proxy.newProxyInstance میکانزم کے ذریعے کال کو روکتا ہے اور اسے HTTP درخواست میں تبدیل کرتا ہے۔ پورا عمل بغیر کوڈ جنریشن کے رن ٹائم پر ہوتا ہے۔

Retrofit.Builder انسٹنس بناتے وقت، بیس URL اور کنورٹر فیکٹری مخصوص کی جاتی ہے۔ Builder OkHttpClient کو ترتیب دیتا ہے — ٹائم آؤٹ، انٹرسیپٹرز، کنکشن پول اور کیش سیٹ کرتا ہے۔ create(Class) طریقہ انٹرفیس کا نفاذ پیدا کرتا ہے، ایک پراکسی آبجیکٹ لوٹاتا ہے جسے عام کلاس کی طرح کال کیا جا سکتا ہے۔

درخواست پر عملدرآمد کا سلسلہ اس طرح ہے: اینوٹیشنز HTTP طریقہ نکالتے ہیں، پیرامیٹرز URL یا درخواست کے باڈی میں ڈالے جاتے ہیں، کنورٹر باڈی کو سیریلائز کرتا ہے، OkHttp درخواست انجام دیتا ہے، کنورٹر جواب کو ڈی سیریلائز کرتا ہے، اور نتیجہ مخصوص ٹائپ میں لوٹایا جاتا ہے۔ ہر مرحلہ الگ تھلگ ہے اور اسے کسٹم نفاذ سے تبدیل کیا جا سکتا ہے، مثلاً ٹیسٹنگ کے لیے OkHttpClient کو MockWebServer سے تبدیل کرنا یا API تبدیل کرتے وقت کنورٹر بدلنا۔

ایک اہم خصوصیت — Retrofit براہ راست سٹریمنگ ڈیٹا ٹرانسمیشن کو سپورٹ نہیں کرتا۔ سٹریمنگ کے لیے، انٹرفیس طریقہ کی واپسی کی قسم کے طور پر OkHttp ResponseBody استعمال ہوتا ہے۔ Retrofit درخواستوں کی منسوخی کو خود بخود منظم نہیں کرتا — منسوخ کرنے کے لیے Call کا حوالہ رکھنا اور cancel() کال کرنا ضروری ہے۔ Kotlin میں suspend فنکشنز کے ساتھ، والدین کوروٹین منسوخ ہونے پر درخواست کی منسوخی خود بخود ہو جاتی ہے۔

Call آبجیکٹ کا لائف سائیکل

Call<T> ایک آبجیکٹ ہے جو ایک HTTP درخواست کی نمائندگی کرتا ہے۔ عملدرآمد (execute یا enqueue) کے بعد، Call کو دوبارہ استعمال نہیں کیا جا سکتا — بار بار درخواست کے لیے انٹرفیس طریقہ کال کر کے نیا Call بنانا ضروری ہے۔ یہ غلطی سے ایک ہی درخواست کو دو بار بھیجنے سے روکتا ہے، جو سرور پر ڈپلیکیٹ آپریشنز کا سبب بن سکتا ہے۔

Kotlin میں، Call کے بجائے suspend فنکشنز استعمال ہوتے ہیں، جو درخواست کے لائف سائیکل کو خود بخود منظم کرتے ہیں۔ Retrofit عملدرآمد کو Dispatchers.IO پر سوئچ کرتا ہے اور نتیجہ کوروٹین کو لوٹاتا ہے۔ یہ Call اور Callback ورژن کے مقابلے میں کوڈ کو 30–40% تک کم کرتا ہے۔

HTTP طریقوں کے لیے Retrofit اینوٹیشنز

اینوٹیشنز Retrofit میں HTTP درخواستوں کو ترتیب دینے کا بنیادی میکانزم ہیں۔ ہر اینوٹیشن ایک معیاری HTTP طریقے سے مطابقت رکھتا ہے اور اینڈپوائنٹ تک نسبتی راستہ قبول کرتا ہے۔ Retrofit GET, POST, PUT, DELETE, PATCH, HEAD اور OPTIONS کو سپورٹ کرتا ہے۔

درخواست پیرامیٹر اینوٹیشنز

@Path URL سیگمنٹ میں قدر ڈالتا ہے: @Path("id") Int id راستے میں {id} کو تبدیل کرتا ہے۔ @Query ایک سوالیہ پیرامیٹر شامل کرتا ہے: @Query("page") Int page ?page=5 میں بدل جاتا ہے۔ @Body منتخب کنورٹر کے ذریعے خودکار سیریلائزیشن کے ساتھ درخواست کے باڈی میں آبجیکٹ منتقل کرتا ہے۔ @Header اور @Headers HTTP ہیڈرز کو منظم کرتے ہیں — جامد یا متحرک۔

ان اینوٹیشنز کو ملا کر، کسی بھی REST اینڈپوائنٹ کو بیان کیا جا سکتا ہے۔ مثال کے طور پر، POST /api/users/{id}/posts?limit=10 اینڈپوائنٹ کے لیے @POST، id کے لیے @Path، limit کے لیے @Query اور منتقل کردہ آبجیکٹ کے لیے @Body درکار ہے۔ Retrofit خود بخود ایک درست HTTP درخواست جمع کرے گا۔ اضافی طور پر @Url (متحرک URL)، @Field (فارم انکوڈ شدہ باڈی)، @Part اور @PartMap فائلوں کے ساتھ ملٹی پارٹ درخواستوں کے لیے معاون ہیں۔

Kotlin میں Retrofit کوڈ کی مثالیں

آئیے ایک عملی مثال دیکھتے ہیں — GitHub API کے لیے ایک انٹرفیس۔ ریپازٹریز کی فہرست حاصل کرنے کے طریقے کے ساتھ ایک Kotlin انٹرفیس بنایا جاتا ہے۔ Repo ڈیٹا کلاس JSON جواب کی ساخت کو بیان کرتا ہے۔

data class Repo(
    val name: String,
    val description: String?,
    val stargazersCount: Int,
    val forksCount: Int
)

interface GitHubApi {
    @GET("users/{user}/repos")
    suspend fun getRepos(
        @Path("user") user: String,
        @Query("sort") sort: String = "updated"
    ): List<Repo>
}

انٹرفیس بیان کرنے کے بعد، Builder کے ذریعے ایک Retrofit انسٹنس بنایا جاتا ہے۔ بیس URL، کنورٹر اور OkHttpClient ایک بار ترتیب دیے جاتے ہیں اور ڈیپنڈنسی انجیکشن کے ذریعے دوبارہ استعمال ہوتے ہیں۔

val retrofit = Retrofit.Builder()
    .baseUrl("https://api.github.com/")
    .addConverterFactory(GsonConverterFactory.create())
    .client(OkHttpClient.Builder()
        .connectTimeout(30, TimeUnit.SECONDS)
        .build())
    .build()

val api = retrofit.create(GitHubApi::class.java)

Response ریپر کے ساتھ جواب ہینڈلنگ

HTTP اسٹیٹس کوڈز کی لچکدار ہینڈلنگ کے لیے، Response<T> ریپر استعمال کریں۔ یہ 4xx اور 5xx غلطیوں پر استثناء پھینکے بغیر جوابی کوڈ، ہیڈرز اور باڈی تک رسائی فراہم کرتا ہے۔ یہ try-catch کے بغیر 404 اور 500 کو ہینڈل کرنے کی اجازت دیتا ہے۔

interface GitHubApi {
    @GET("users/{user}/repos")
    suspend fun getRepos(
        @Path("user") user: String
    ): Response<List<Repo>>
}

val response = api.getRepos("octocat")
if (response.isSuccessful) {
    println(response.body()?.size)
} else {
    Log.e("API", "Error: ${response.code()}")
}

Retrofit میں کنورٹرز اور سیریلائزیشن

کنورٹرز Retrofit کے وہ اجزاء ہیں جو آبجیکٹ کو HTTP باڈی میں اور اس کے برعکس تبدیل کرنے کے ذمہ دار ہیں۔ Retrofit سیریلائزیشن کو اپنے کور میں شامل نہیں کرتا — بلکہ یہ Converter.Factory کے ذریعے ماڈیولر نقطہ نظر استعمال کرتا ہے، جو کسی بھی سیریلائزیشن لائبریری کو پلگ ان کرنے کی اجازت دیتا ہے۔

سب سے مشہور کنورٹر Gson لائبریری پر مبنی Google کا GsonConverterFactory ہے۔ یہ زیادہ تر منصوبوں کے لیے کام کرتا ہے، کسٹم TypeAdapter اور JsonDeserializer کو سپورٹ کرتا ہے۔ تاہم، Gson ریفلیکشن استعمال کرتا ہے اور Kotlin کی null سیفٹی کا احترام نہیں کرتا، جو غیر متوقع null فیلڈز پر NPE کا سبب بن سکتا ہے۔

ایک متبادل Square کا MoshiConverterFactory ہے: ٹائپس کے ساتھ زیادہ سخت، بہتر Kotlin سپورٹ (null سیفٹی، ڈیفالٹ ویلیوز) اور ریفلیکشن کے بغیر۔ خالص Kotlin منصوبوں کے لیے، Kotlinx Serialization Converter بہترین ہے، جو کمپائل ٹائم پر @Serializable اینوٹیشنز کے ساتھ کام کرتا ہے۔ یہ ریفلیکشن استعمال نہیں کرتا، sealed class، ڈیفالٹ ویلیوز اور ملٹی پلیٹ فارم کو سپورٹ کرتا ہے۔

کنورٹر کا انتخاب کارکردگی اور ٹائپ سیفٹی کو متاثر کرتا ہے۔ Gson کسٹم کنفیگریشن کے بغیر Kotlin کے non-null فیلڈ میں null کو ڈی سیریلائز کر سکتا ہے، جس سے رسائی پر NPE ہوتا ہے۔ Moshi @Json(name) اینوٹیشن اور failOnUnknown کے ذریعے اس مسئلے کو حل کرتا ہے۔ Kotlinx Serialization سب سے محفوظ ہے — یہ کمپائل ٹائم پر کوڈ پیدا کرتا ہے، رن ٹائم ٹائپ کی غلطیوں کو مکمل طور پر ختم کرتا ہے۔

Retrofit کے ساتھ کام کرتے وقت عام غلطیاں

Suspend فنکشنز میں HTTP غلطی ہینڈلنگ کی کمی سب سے عام مسئلہ ہے۔ اگر سرور 4xx یا 5xx لوٹاتا ہے، تو Retrofit HttpException پھینکتا ہے۔ try-catch کے بغیر، ایپ کریش ہو جاتی ہے۔ واپسی کی قسم کے طور پر Response<T> استعمال کرنا اس مسئلے کو حل کرتا ہے، باڈی تک رسائی سے پہلے isSuccessful چیک کرنے کی اجازت دیتا ہے۔

غلط کیش کنفیگریشن ضرورت سے زیادہ ٹریفک کا باعث بنتی ہے۔ Retrofit خود جوابات کو کیش نہیں کرتا — یہ کام OkHttpClient Cache کے ذریعے کرتا ہے۔ کیش کے بغیر، ہر درخواست مکمل طور پر انجام دی جاتی ہے، چاہے ڈیٹا تبدیل نہ ہوا ہو۔ OkHttpClient میں 10 MB کیش شامل کرنے سے ایک ہی معلومات کی بار بار درخواستوں پر ٹریفک 40–60% کم ہو جاتا ہے۔

ہر درخواست کے لیے Retrofit بنانا ابتدائی افراد کی عام غلطی ہے۔ Retrofit.Builder ایک وسائل پر مبنی آپریشن ہے جس میں رن ٹائم پر پراکسی کلاسز کی تخلیق شامل ہے۔ صحیح طریقہ ایک Retrofit انسٹنس بنانا اور اسے DI فریم ورکس کے ذریعے دوبارہ استعمال کرنا ہے۔ Hilt, Koin یا Dagger پوری ایپ کے لیے ایک سنگلٹن Retrofit انسٹنس فراہم کرتے ہیں، میموری بچاتے ہیں اور درخواستوں کو تیز کرتے ہیں۔

اختیار کے لیے Interceptor کو نظر انداز کرنا چوتھا مسئلہ ہے۔ ہر کال میں دستی طور پر Authorization ہیڈر شامل کرنے کے بجائے، OkHttpClient میں ایک گلوبل Interceptor ترتیب دیں۔ Interceptor ہر درخواست کو روکتا ہے، Bearer ٹوکن شامل کرتا ہے، اور Authenticator 401 جواب کو ہینڈل کرتا ہے، ٹوکن ریفریش کرتا ہے اور خود بخود درخواست دہراتا ہے۔ یہ توثیقی منطق کو مرکزی بناتا ہے۔