REST API: یہ کیا ہے، HTTP طریقے اور موبائل ایپلیکیشنز میں کام کا اصول

REST API کیا ہے؟

REST API (Representational State Transfer API) ایک آرکیٹیکچرل انداز ہے جو رائے فیلڈنگ نے 2000 میں اپنے ڈاکٹریٹ مقالے میں تجویز کیا تھا۔ یہ نیٹ ورک پروٹوکول ڈیزائن کرنے کے لیے رکاوٹوں اور اصولوں کا ایک سیٹ متعین کرتا ہے۔ ان رکاوٹوں پر پورا اترنے والی API کو RESTful کہا جاتا ہے۔ REST کوئی پروٹوکول یا معیار نہیں ہے — یہ ایک آرکیٹیکچرل نقطہ نظر ہے جو کلائنٹ اور سرور کے درمیان ڈیٹا کے تبادلے کے لیے موجودہ پروٹوکول (بنیادی طور پر HTTP) استعمال کرتا ہے۔

REST کا بنیادی خیال وسیلہ پر مبنی آرکیٹیکچر ہے۔ سرور پر طریقوں کو کال کرنے کے بجائے (جیسے SOAP یا RPC میں)، کلائنٹ وسائل پر کام کرتا ہے: فہرستیں حاصل کرتا ہے، نئی تخلیق کرتا ہے، اپ ڈیٹ یا حذف کرتا ہے۔ ہر وسیلہ ایک ڈومین وجود ہے: صارف، آرڈر، پروڈکٹ، مضمون۔ ایک وسیلہ کی ایک حالت ہوتی ہے جو کلائنٹ کو معیاری فارمیٹ میں بھیجی جاتی ہے، عام طور پر JSON۔ سرور درخواستوں کے درمیان کلائنٹ کی حالت ذخیرہ نہیں کرتا — یہ stateless اصول ہے، REST کی ایک اہم ضرورت۔

REST API کی اہم خصوصیات:

• Stateless — کلائنٹ کی ہر درخواست اس کی پروسیسنگ کے لیے تمام ضروری معلومات پر مشتمل ہوتی ہے
• Cacheable — سرور کے جوابات کو واضح طور پر کیش ایبل یا نان کیش ایبل کے طور پر نشان زد کیا جانا چاہیے
• Layered system — آرکیٹیکچر میں درمیانی سرور، لوڈ بیلنسر، پراکسی شامل ہو سکتے ہیں
• Uniform interface — HTTP طریقوں، URL اور اسٹیٹس کوڈز کے ذریعے ایک متحد انٹرفیس

REST آرکیٹیکچر کے اصول

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

Uniform Interface کے اصول میں مزید چار ذیلی رکاوٹیں شامل ہیں: URI کے ذریعے وسیلہ کی شناخت، نمائندگیوں کے ذریعے وسیلہ کا انتظام، خود وضاحتی پیغامات اور HATEOAS (ایپلیکیشن اسٹیٹ کے انجن کے طور پر ہائپر میڈیا)۔ آخری ذیلی رکاوٹ کو اکثر عملی طور پر نظر انداز کیا جاتا ہے — زیادہ تر جدید REST API مکمل طور پر HATEOAS لاگو نہیں کرتیں، جس سے بحث ہوتی ہے کہ کیا ایسی API “واقعی” RESTful ہے۔

Stateless کا اصول اسکیلنگ کے لیے سب سے اہم ہے۔ سرور پر سیشنز کی عدم موجودگی کا مطلب ہے کہ کوئی بھی سرور انسٹنس کسی بھی درخواست کو پروسیس کر سکتا ہے۔ یہ افقی اسکیلنگ کو آسان بناتا ہے: لوڈ بیلنسر کے پیچھے نئے سرورز شامل کریں۔ موبائل ایپلیکیشنز کے لیے، stateless کا یہ بھی مطلب ہے کہ درخواست کسی بھی CDN سرور کو بھیجی جا سکتی ہے، جو عالمی دستیابی کے لیے اہم ہے۔

REST میں HTTP طریقے

REST API میں ہر HTTP طریقہ ایک وسیلہ پر مخصوص کارروائی سے مطابقت رکھتا ہے: پڑھنے کے لیے GET، بنانے کے لیے POST، مکمل اپ ڈیٹ کے لیے PUT، جزوی اپ ڈیٹ کے لیے PATCH، حذف کرنے کے لیے DELETE۔ طریقوں کی idempotence ایک اہم خصوصیت ہے: GET، PUT، DELETE idempotent ہیں (بار بار عمل یکساں نتیجہ دیتا ہے)، POST اور PATCH نہیں ہیں۔ یہ نیٹ ورک کی خرابیوں کو سنبھالنے کے لیے اہم ہے جب کلائنٹ کو معلوم نہ ہو کہ درخواست سرور تک پہنچی یا نہیں۔

• GET — وسیلہ یا وسائل کی فہرست حاصل کرنا۔ Idempotent، سرور کی حالت نہیں بدلتا
• POST — نیا وسیلہ بنانا۔ Idempotent نہیں، ہر کال نیا وسیلہ بناتی ہے
• PUT — وسیلہ کی مکمل تبدیلی۔ Idempotent، پہلے کے بعد بار بار کالیں حالت نہیں بدلتیں
• PATCH — وسیلہ کی جزوی اپ ڈیٹ۔ جزوی طور پر idempotent (عملدرآمد پر منحصر)
• DELETE — وسیلہ حذف کرنا۔ Idempotent، بار بار حذف کرنے پر 404 ملتا ہے، خرابی نہیں

HTTP اسٹیٹس کوڈ REST API کا ایک لازمی حصہ ہیں۔ ہر کوڈ کا ایک مخصوص معنی ہوتا ہے: کامیاب GET کے لیے 200 OK، POST کے لیے 201 Created، جوابی باڈی کے بغیر DELETE کے لیے 204 No Content، نا مناسب ڈیٹا کے لیے 400 Bad Request، تصدیق کی کمی پر 401 Unauthorized، وسیلہ نہ ملنے پر 404 Not Found۔ اسٹیٹس کوڈ کا صحیح استعمال API کو خود دستاویزی بناتا ہے اور ڈیبگنگ کو آسان بناتا ہے۔

ڈیٹا فارمیٹس: JSON اور دیگر

JSON (JavaScript Object Notation) REST API میں ڈیٹا کی منتقلی کا بنیادی فارمیٹ ہے۔ اس کی مقبولیت سادگی، انسانی پڑھنے کی اہلیت اور JavaScript میں مقامی سپورٹ کی وجہ سے ہے۔ JSON کو Content-Type: application/json ہیڈر کے ساتھ منتقل کیا جاتا ہے۔ متبادلات میں XML (لمبا، پرانا)، YAML (کنفیگریشن کے لیے آسان، API کے لیے کم عام) اور Protocol Buffers (بائنری، زیادہ بوجھ والے نظاموں کے لیے موثر) شامل ہیں۔

REST API میں JSON آبجیکٹ کی ساخت میں عام طور پر id، type فیلڈز اور وسیلہ کی خصوصیات شامل ہوتی ہیں۔ مجموعوں کے لیے، پیجینیشن میٹا ڈیٹا کے ساتھ JSON صف استعمال کی جاتی ہے۔ جدید REST API جوابی توثیق کے لیے JSON:API تصریح (jsonapi.org) یا JSON Schema کی پیروی کرتی ہیں۔ متحد ڈیٹا فارمیٹ کا استعمال کلائنٹ لائبریری کی ترقی اور دستاویزات کی تخلیق کو آسان بناتا ہے۔

صارفین کی فہرست کے لیے JSON جواب کی مثال:

{
    "data": [
        {
            "id": 1,
            "name": "انا پیٹرووا",
            "email": "anna@example.com"
        }
    ],
    "meta": {
        "total": 42,
        "page": 1,
        "per_page": 10
    }
}

ڈیٹا کی منتقلی کے فارمیٹ کا انتخاب موبائل ایپلیکیشن کی کارکردگی کو متاثر کرتا ہے۔ JSON GZIP کے ذریعے 70-80% کمپریس ہوتا ہے، جو اسے زیادہ تر منظرناموں کے لیے قابل قبول بناتا ہے۔ بڑے ڈیٹا والیم (سٹریمنگ، گیمنگ) والی ریئل ٹائم ایپلیکیشنز کے لیے، بائنری پروٹوکول پر سوئچ کرنے یا Protocol Buffers کے ساتھ WebSocket استعمال کرنے کی سفارش کی جاتی ہے۔

REST API درخواستوں کی مثالیں

آئیے موبائل ایپلیکیشن کی طرف سے REST API کے ساتھ کام کرنے کی عملی مثالیں دیکھتے ہیں۔ مثال کے طور پر، ایک آن لائن اسٹور میں آرڈرز کے ساتھ کام کرنے کے لیے API لیتے ہیں۔ ہر HTTP طریقہ کے لیے، ایک درخواست اور متوقع سرور جواب دکھایا گیا ہے۔ مثالیں موبائل ڈویلپمنٹ میں استعمال ہونے والے عام RESTful API ڈھانچے کو ظاہر کرتی ہیں۔

GET — آرڈرز کی فہرست حاصل کرنا

پیجینیشن کے ساتھ تمام صارف آرڈرز حاصل کرنے کی درخواست۔ جواب میں آرڈر آبجیکٹس کی ایک صف اور صفحہ نیویگیشن کے لیے میٹا معلومات ہوتی ہے۔ page اور per_page پیرامیٹرز query string کے ذریعے بھیجے جاتے ہیں۔

// REST API کے لیے Retrofit انٹرفیس
interface OrderApi {
    @GET("api/v1/orders")
    suspend fun getOrders(
        @Query("page") page: Int = 1,
        @Query("per_page") perPage: Int = 20
    ): Response<OrderListResponse>
}

POST — نیا آرڈر بنانا

POST درخواست کے ذریعے نیا آرڈر بنانا۔ سرور 201 Created اسٹیٹس اور جوابی باڈی میں بنائی گئی آبجیکٹ واپس کرتا ہے۔ اہم: تخلیق مخصوص وسیلہ پر نہیں، بلکہ /api/v1/orders مجموعے پر کی جاتی ہے — یہ معیاری RESTful پیٹرن ہے۔

@POST("api/v1/orders")
suspend fun createOrder(
    @Body order: CreateOrderRequest
): Response<OrderResponse>

// درخواست باڈی کی مثال
data class CreateOrderRequest(
    val productId: String,
    val quantity: Int,
    val addressId: String
)

DELETE — آرڈر حذف کرنا

وسیعہ کو حذف کرنا مخصوص آرڈر URL پر DELETE طریقہ سے کیا جاتا ہے۔ کامیاب حذف 204 No Content واپس کرتا ہے۔ DELETE کی idempotence کا مطلب ہے کہ اسی URL پر بار بار درخواست 404 Not Found واپس کرتی ہے، جسے کلائنٹ پر صحیح طریقے سے سنبھالا جاتا ہے۔

@DELETE("api/v1/orders/{id}")
suspend fun deleteOrder(
    @Path("id") orderId: String
): Response<Unit>

// ViewModel میں استعمال
fun removeOrder(orderId: String) {
    viewModelScope.launch {
        val response = api.deleteOrder(orderId)
        if (response.isSuccessful) {
            showSuccess()
        }
    }
}

یہ مثالیں Retrofit اور Kotlin Coroutines استعمال کرتے ہوئے Android کی طرف عام REST API عملدرآمد کو ظاہر کرتی ہیں۔ iOS ایپلیکیشنز کے لیے، URLSession یا Alamofire لائبریری Codable پروٹوکول کے ساتھ مل کر اسی طرح کا کردار ادا کرتی ہے۔ REST API کا ڈھانچہ پلیٹ فارم سے قطع نظر یکساں رہتا ہے — صرف درخواست کرنے کا طریقہ بدلتا ہے۔

RESTful API ڈیزائن: عملی سفارشات

اعلیٰ معیار کی RESTful API ڈیزائن کرنے کے لیے ایسے کنونشنز پر عمل کرنا ضروری ہے جو API کو ڈویلپرز کے لیے بدیہی بنائیں۔ وسائل کو جمع اسماء (/users، /orders، /products) سے نامزد کیا جانا چاہیے، HTTP طریقوں کو کارروائیوں کی عکاسی کرنی چاہیے اور URLs کو nesting درجہ بندی کی نمائندگی کرنی چاہیے۔ خرابیوں کو صرف HTTP اسٹیٹس نہیں، بلکہ کوڈ اور پیغام کے ساتھ معیاری JSON واپس کرنا چاہیے۔ ان کنونشنز کی پیروی نئے ڈویلپرز کے لیے داخلے کی رکاوٹ کو کم کرتی ہے اور انضمام کو آسان بناتی ہے۔

• وسیلہ نامزدگی — جمع، kebab-case: /api/v1/user-orders، /api/v1/getUserOrders نہیں
• فلٹرنگ اور ترتیب — query پیرامیٹرز کے ذریعے: ?status=active&sort=created_at:desc
• پیجینیشن — بڑے سیٹ کے لیے کرسر پر مبنی، چھوٹے کے لیے صفحہ پر مبنی
• ورژن کنٹرول — URL (/api/v2/) یا Accept-Version ہیڈر کے ذریعے
• خرابیاں — متحد فارمیٹ: { "error": { "code": "VALIDATION_ERROR", "message": "..." } }
• ریٹ لمیٹنگ — X-RateLimit-Remaining اور Retry-After ہیڈر

REST API ڈیزائن کرتے وقت ایک عام غلطی ضرورت سے زیادہ وسائل کا nesting ہے۔ /users/1/orders/5/items/3 کے بجائے، query پیرامیٹرز کے ساتھ فلیٹ ڈھانچہ استعمال کرنا بہتر ہے: /items?order_id=5&user_id=1۔ یہ کیشنگ کو آسان بناتا ہے، سرور پر لمبے راستے برقرار رکھنے کی ضرورت نہیں ہوتی اور دستاویز کرنا آسان ہوتا ہے۔ فلیٹ آرکیٹیکچر مستقبل میں GraphQL پر منتقلی کے وقت گراف پر مبنی سوالات کے ساتھ بہتر مطابقت رکھتا ہے۔

REST API سیکیورٹی تصدیق (JWT، OAuth 2.0) اور وسیلہ کی سطح پر اختیار کے ذریعے لاگو کی جاتی ہے۔ ہر درخواست کو چیک کرنا چاہیے کہ صارف کے پاس مطلوبہ وسیلہ تک رسائی ہے یا نہیں۔ HTTPS لازمی ہے — خفیہ کاری کے بغیر، ٹوکنز اور ڈیٹا سادہ متن میں منتقل ہوتے ہیں۔ موبائل ایپلیکیشنز کے لیے، محفوظ ٹوکن حصول کے لیے PKCE (Proof Key for Code Exchange) کے ساتھ OAuth 2.0 استعمال کرنے کی سفارش کی جاتی ہے۔

ورژن کنٹرول اور کیشنگ

REST API کا ورژن کنٹرول تبدیلیوں کے دوران پسماندہ مطابقت کے لیے ضروری ہے۔ سب سے عام طریقے ہیں: URL میں ورژن (/api/v1/orders)، ہیڈر میں ورژن (Accept: application/vnd.myapi.v1+json) اور query پیرامیٹر میں ورژن (?api_version=1)۔ URL ورژننگ سب سے مقبول طریقہ ہے کیونکہ یہ لاگز اور دستاویزات میں واضح طور پر نظر آتا ہے۔ تاہم، یہ فی وسیلہ ایک URL کے REST اصول کی خلاف ورزی کرتا ہے۔

REST API میں کیشنگ HTTP ہیڈر Cache-Control، ETag اور Last-Modified کے ذریعے لاگو کی جاتی ہے۔ کیش ایبل کے طور پر نشان زد GET درخواستیں سرور سے رابطہ کیے بغیر براؤزر یا پراکسی کیش سے فراہم کی جا سکتی ہیں۔ موبائل ایپلیکیشنز کے لیے، کیشنگ خاص طور پر اہم ہے — یہ ڈیٹا کے استعمال کو کم کرتی ہے اور کمزور کنیکٹیویٹی پر پہلے سے لوڈ کردہ ڈیٹا کے ڈسپلے کو تیز کرتی ہے۔ ETag جوابی مواد کا ایک ہیش ہے: کلائنٹ اسے If-None-Match میں بھیجتا ہے اور اگر ڈیٹا تبدیل نہیں ہوا تو سرور 304 Not Modified واپس کرتا ہے۔

REST API کے جدید متبادلات میں GraphQL (لچکدار کلائنٹ سائیڈ ڈیٹا حاصل کرنا) اور gRPC (مائیکرو سروسز کے لیے HTTP/2 پر بائنری پروٹوکول) شامل ہیں۔ تاہم، REST اپنی سادگی، آفاقیت اور وسیع ٹول سپورٹ کی وجہ سے عوامی API کے لیے بنیادی معیار بنا ہوا ہے۔ REST اور متبادلات کے درمیان انتخاب کا انحصار پروجیکٹ کی مخصوص ضروریات پر ہے: سوال کی پیچیدگی، ڈیٹا کا حجم، ریئل ٹائم اپ ڈیٹ کی ضروریات۔