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। विधियों की आइडेम्पोटेंसी एक मुख्य विशेषता है: GET, PUT, DELETE आइडेम्पोटेंट हैं (बार-बार निष्पादन एक ही परिणाम देता है), POST और PATCH नहीं हैं। यह नेटवर्क त्रुटियों को संभालने के लिए महत्वपूर्ण है जब क्लाइंट को नहीं पता होता कि अनुरोध सर्वर तक पहुंचा या नहीं।

• GET — संसाधन या संसाधनों की सूची प्राप्त करना। आइडेम्पोटेंट, सर्वर स्थिति नहीं बदलता
• POST — नया संसाधन बनाना। आइडेम्पोटेंट नहीं, प्रत्येक कॉल एक नया संसाधन बनाता है
• PUT — संसाधन का पूर्ण प्रतिस्थापन। आइडेम्पोटेंट, पहले के बाद बार-बार कॉल स्थिति नहीं बदलते
• PATCH — संसाधन का आंशिक अपडेट। आंशिक रूप से आइडेम्पोटेंट (कार्यान्वयन पर निर्भर करता है)
• DELETE — संसाधन हटाना। आइडेम्पोटेंट, बार-बार हटाने पर 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 की आइडेम्पोटेंसी का मतलब है कि उसी 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()
        }
    }
}

ये उदाहरण Android पक्ष पर Retrofit और Kotlin Coroutines का उपयोग करके एक सामान्य REST API कार्यान्वयन प्रदर्शित करते हैं। iOS एप्लिकेशन के लिए, URLSession या Alamofire लाइब्रेरी Codable प्रोटोकॉल के साथ समान भूमिका निभाती है। REST API संरचना प्लेटफ़ॉर्म के बावजूद समान रहती है — केवल अनुरोध करने का तरीका बदलता है।

RESTful API डिज़ाइन: व्यावहारिक सुझाव

गुणवत्तापूर्ण RESTful API डिज़ाइन करने के लिए ऐसी परंपराओं का पालन करना आवश्यक है जो API को डेवलपर्स के लिए सहज बनाती हैं। संसाधनों को बहुवचन संज्ञाओं (/users, /orders, /products) में नामित किया जाना चाहिए, HTTP विधियों को संचालन को प्रतिबिंबित करना चाहिए, और URL को नेस्टिंग पदानुक्रम को दर्शाना चाहिए। त्रुटियों को सिर्फ 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 डिज़ाइन करते समय एक सामान्य गलती अत्यधिक संसाधन नेस्टिंग है। /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 और विकल्पों के बीच चुनाव परियोजना की विशिष्ट आवश्यकताओं पर निर्भर करता है: क्वेरी जटिलता, डेटा वॉल्यूम, रीयल-टाइम अपडेट की आवश्यकताएँ।