REST बनाम GraphQL: फर्क क्या है और कौन सा इस्तेमाल करें?

REST और GraphQL, API डिज़ाइन करने के दो तरीके हैं, यानी वह तय तरीका जिससे आपके app की स्क्रीन (या दूसरे programs) आपके backend से डेटा माँगते हैं। REST में हर तरह की चीज़ के लिए अलग URL होता है, जैसे /customers या /orders, और हर एक तय shape का डेटा लौटाता है। GraphQL में आम तौर पर एक ही URL होता है, और caller एक query भेजता है जिसमें लिखा होता है कि उसे कौन से fields वापस चाहिए। AI से बने ज़्यादातर apps के लिए REST सरल और बेहतर डिफ़ॉल्ट है।

AI से बनाते समय यह क्यों मायने रखता है

जब आप किसी AI builder से "backend वाला app" माँगते हैं, तो उसे तय करना होता है कि frontend और backend आपस में कैसे बात करेंगे। यह हर बार आपको तय नहीं करना पड़ता, लेकिन code, documentation और बाहरी सेवाओं से जुड़ते समय ये शब्द दिखेंगे। कुछ सेवाएँ केवल एक स्टाइल देती हैं: बहुत सारी सेवाएँ REST APIs देती हैं, जबकि कुछ, जैसे Shopify और GitHub, GraphQL भी देती या उसे प्राथमिकता देती हैं। फर्क जानने से आप समझ पाते हैं कि आप क्या देख रहे हैं, और वह complexity नहीं जोड़ते जिसकी ज़रूरत नहीं। अगर "API" आपके लिए नया है, तो पहले API क्या है पढ़ें।

रोज़मर्रा की एक मिसाल

REST एक set menu वाले रेस्टोरेंट जैसा है। हर dish (endpoint) वैसे ही आती है जैसे रसोई ने तय की है। आप "customer" dish मँगाते हैं और पूरी plate मिलती है: नाम, email, address, signup date, भले ही आपको सिर्फ़ नाम चाहिए था। ग्राहक के हाल के orders भी चाहिए? वह एक दूसरी dish है।

GraphQL एक ही waiter से à la carte ऑर्डर करने जैसा है। आप लिख देते हैं कि ठीक-ठीक क्या चाहिए: "ग्राहक का नाम, और उसके आख़िरी तीन orders की तारीख और total।" एक ऑर्डर, एक plate, और सिर्फ़ वही जो आपने माँगा। लेकिन रसोई को किसी भी संभावित combination को संभालने के लिए तैयार होना पड़ता है।

एक ही request, दोनों तरीकों से

मान लीजिए ग्राहक के पेज को ग्राहक का नाम और उसके तीन सबसे नए orders चाहिए।

REST में, आम तौर पर दो requests होती हैं:

GET /api/customers/42
GET /api/customers/42/orders?limit=3

पहले response में पेज की ज़रूरत से ज़्यादा भी हो सकता है:

{ "id": 42, "name": "Lena Park", "email": "lena@example.com", "address": "…", "createdAt": "…" }

GraphQL में, यह एक request है, आम तौर पर /graphql जैसे एक endpoint पर POST, जिसमें query है:

query {
  customer(id: 42) {
    name
    orders(last: 3) {
      date
      total
    }
  }
}

और response query के हिसाब से ही दिखता है:

{
  "data": {
    "customer": {
      "name": "Lena Park",
      "orders": [
        { "date": "2026-09-20", "total": 48.0 },
        { "date": "2026-09-02", "total": 19.5 },
        { "date": "2026-08-15", "total": 72.25 }
      ]
    }
  }
}

दोनों JSON लौटाते हैं। फर्क इस पर है कि shape कौन तय करता है: REST में server, और GraphQL में caller, जो server के schema की सीमा के भीतर चुनता है।

एक नज़र में तुलना

किसके लिए कौन सा सही है

REST चुनें जब:

• आप एक आम app बना रहे हैं: booking system, CRM, dashboard, store।
• एक frontend एक backend से बात करता है, और दोनों आपके नियंत्रण में हैं।
• आपको सबसे सरल चीज़ चाहिए जिसे debug, cache और सुरक्षित करना आसान हो।
• बाहरी सेवाएँ आपके app को call करेंगी (webhooks और ज़्यादातर integrations REST-शैली के endpoints माँगते हैं)।

GraphQL पर विचार करें जब:

• कई अलग clients, जैसे website, mobile app और partner integrations, एक ही डेटा के बहुत अलग हिस्से चाहते हैं।
• आपका डेटा गहराई से जुड़ा है (products, variants, reviews, sellers, inventory) और स्क्रीन को उसे कई तरीकों से जोड़ना पड़ता है।
• आप ऐसी सेवा इस्तेमाल कर रहे हैं जिसका मुख्य API GraphQL है।

एक उपयोगी नियम: अगर आपको पक्का नहीं कि GraphQL चाहिए, तो शायद अभी नहीं चाहिए। इसे बाद में जोड़ना, हटाने से आसान है।

मुख्य शब्द

आम गलतफ़हमियाँ

• "GraphQL नया है, इसलिए बेहतर है।" यह ख़ास समस्याएँ सुलझाता है। एक frontend वाले एक app के लिए अक्सर यह काम बढ़ाता है, फ़ायदा कम देता है।
• "GraphQL एक database है।" ऐसा नहीं है। यह एक API layer है; इसके पीछे server अभी भी आपके database से पढ़ता है।
• "GraphQL हमेशा तेज़ होता है।" कम requests धीमे mobile networks पर मदद कर सकती हैं, लेकिन एक बेलगाम query बहुत सारा डेटा लोड कर सकती है। प्रदर्शन backend पर निर्भर करता है।
• "REST का मतलब सख़्त मानक है।" व्यवहार में "REST API" ढीले तौर पर resource URLs, HTTP methods और JSON को कहा जाता है। कई अच्छे APIs औपचारिक नियमों को मोड़ते हैं।
• "Status 200 का मतलब है कि काम हो गया।" GraphQL में errors field जाँचें: एक request आंशिक रूप से फेल हो सकती है और फिर भी 200 लौटा सकती है।

अपने AI builder से क्या पूछें

• "सरल REST API और JSON इस्तेमाल करो, जब तक कोई ठोस वजह न हो। अगर लगे कि GraphQL ज़रूरी है तो बताओ।"
• "हर endpoint की सूची दो, वह क्या लौटाता है और उसे कौन call कर सकता है।"
• "ग्राहक वाले पेज के लिए सिर्फ़ वही fields लौटाओ जो पेज इस्तेमाल करता है।"
• "List endpoints में pagination जोड़ो ताकि वे एक साथ हज़ारों rows न लौटाएँ।"
• "इस सेवा का सिर्फ़ GraphQL API है। इसे server से call करो, key को secret में रखो, और सिर्फ़ ज़रूरी fields माँगो।"
• "सही HTTP status codes और JSON error messages लौटाओ।"

Mythex में REST और GraphQL

Mythex के docs में REST API backend बनाने की एक recipe है, जिसमें starter prompt है, और backend आपके web app के साथ Node, Python (FastAPI), C# या Java में चल सकता है। Docs में GraphQL template का वर्णन नहीं है, इसलिए अगर आपको वह चाहिए तो साफ़ माँगें और कारण बताएँ। किसी तीसरे पक्ष के GraphQL API को call करना किसी भी बाहरी सेवा जैसा ही है; देखें कोई भी API जोड़ें। संबंधित पढ़ाई: frontend बनाम backend और REST API कैसे बनाएँ।

सवाल