API डिज़ाइन: REST, GraphQL और gRPC — किसे चुनें

Blog

हर आधुनिक ऐप्लिकेशन दूसरे ऐप्लिकेशनों से API के ज़रिये बात करता है। सवाल अब यह नहीं कि API बनाएँ या नहीं, बल्कि यह कि किस शैली का API बनाएँ। REST एक दशक से अधिक समय तक डिफ़ॉल्ट रहा है। GraphQL REST के लचीलेपन की कमी की प्रतिक्रिया के रूप में उभरा। gRPC बिल्कुल अलग रास्ता लेता है, जो HTTP/2 और प्रोटोकॉल बफ़र्स पर टिका है। इनके बीच चुनाव के लिए केवल वाक्य-विन्यास नहीं, बल्कि हर एक के पीछे के डिज़ाइन-दर्शन को समझना ज़रूरी है।

यह मार्गदर्शिका हर प्रोटोकॉल को डिज़ाइन की दृष्टि से खोलती है: आप संसाधनों या स्कीमा को कैसे गढ़ते हैं, क्लाइंट आपके API से कैसे बात करते हैं, संस्करण और पृष्ठांकन कैसे संभालते हैं, और वास्तविक-समय की ज़रूरतें फ़ैसले को कैसे मोड़ती हैं। अंत तक आपके पास अपनी बाध्यताओं के लिए सही औज़ार चुनने का ढाँचा होगा।

REST: संसाधन-केंद्रित डिज़ाइन जिसे वेब समझता है

REST — Representational State Transfer — कोई प्रोटोकॉल नहीं है। यह एक स्थापत्य शैली है जिसे रॉय फ़ील्डिंग ने 2000 में अपने शोध-प्रबंध में परिभाषित किया। मूल विचार यह है कि आप अपने डोमेन को संसाधनों के रूप में मॉडल करें, हर संसाधन की पहचान एक URL से हो, और उन संसाधनों से HTTP क्रियाओं के एक समान समुच्चय के ज़रिये व्यवहार करें: GET, POST, PUT, PATCH और DELETE।

अच्छा REST डिज़ाइन संसाधन-केंद्रित डिज़ाइन है। आप एंडपॉइंट क्रियाओं के इर्द-गिर्द नहीं, संज्ञाओं के इर्द-गिर्द गढ़ते हैं। /createUser या /getUserById के बजाय आप POST /users और GET /users/:id बनाते हैं। यह छोटा-सा अंतर लगता है, पर यह गहराई से तय करता है कि API कैसे बढ़ेगा, कैसे दस्तावेज़ीकृत होगा और क्लाइंट उसे उपयोग करना कैसे सीखेंगे।

GET /users/42
Accept: application/json

Response 200:
{
  "id": 42,
  "name": "Ada Lovelace",
  "email": "ada@example.com",
  "role": "admin",
  "createdAt": "2025-11-14T09:00:00Z"
}

REST की सुंदरता उसकी सरलता है। URL संसाधन बताता है, HTTP विधि क्रिया बताती है, और प्रतिक्रिया का भाग प्रतिनिधित्व रखता है। हर भाषा का हर HTTP क्लाइंट इस अनुबंध को समझता है। कैशिंग HTTP शीर्षकों से सीधे काम करती है। OpenAPI जैसे औज़ार आपको एक ही स्कीमा फ़ाइल से दस्तावेज़, क्लाइंट SDK और सर्वर ढाँचे बनाने देते हैं।

REST में दिक़्क़त तब आती है जब अलग-अलग क्लाइंट को डेटा के अलग आकार चाहिए। मोबाइल क्लाइंट को बस उपयोगकर्ता का नाम और भूमिका चाहिए, जबकि डैशबोर्ड को नेस्टेड संगठन-डेटा के साथ पूरा प्रोफ़ाइल। REST में या तो आप कई एंडपॉइंट बनाते हैं, या हर क्लाइंट को पूरा प्रतिनिधित्व उतारकर बेकार हिस्सा फेंकने पर मजबूर करते हैं। यही अति-प्राप्ति की समस्या है, और यही GraphQL की मुख्य प्रेरणा थी।

GraphQL: क्लाइंट ठीक-ठीक बताए कि उसे क्या चाहिए

GraphQL, जिसे Meta ने विकसित किया और 2015 में खुला किया, उल्टा रास्ता लेता है। सर्वर तय प्रतिक्रियाएँ परिभाषित करने के बजाय, क्लाइंट एक पूछताछ भेजता है जो ठीक वही डेटा बताती है जो उसे चाहिए, और सर्वर ठीक वही आकार लौटाता है। एक एंडपॉइंट, कोई भी प्रतिक्रिया-आकार।

GraphQL स्कीमा आपके डोमेन के प्रकार और उनके संबंध परिभाषित करता है। क्लाइंट इसी स्कीमा के विरुद्ध पूछताछ बनाता है और केवल उन्हीं फ़ील्ड माँगता है जिनकी उसे ज़रूरत है। REST के नेस्टेड संसाधनों की वही धारणा GraphQL में नेस्टेड फ़ील्ड बन जाती है, पर गहराई और चुनाव क्लाइंट के हाथ में रहते हैं।

type User {
  id: ID!
  name: String!
  email: String!
  role: Role!
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
  body: String!
}

enum Role { USER ADMIN MODERATOR }

type Query {
  user(id: ID!): User
}

जिस क्लाइंट को केवल उपयोगकर्ता का नाम और पोस्ट के शीर्षक चाहिए, वह ठीक उन्हीं फ़ील्ड की पूछताछ भेजता है:

query {
  user(id: 42) {
    name
    posts {
      title
    }
  }
}

{
  "data": {
    "user": {
      "name": "Ada Lovelace",
      "posts": [
        { "title": "Notes on the Analytical Engine" }
      ]
    }
  }
}

GraphQL का मुख्य डिज़ाइन-सिद्धांत यह है कि स्कीमा ही अनुबंध है। स्कीमा बताता है कि क्या संभव है, और क्लाइंट तय करता है कि उपलब्ध विकल्पों में से क्या माँगना है। इससे अति-प्राप्ति ख़त्म होती है, नेटवर्क अनुरोधों की संख्या घटती है (एक पूछताछ कई REST चक्कर बदल सकती है), और फ़्रंटएंड टीमें बैकएंड बदलावों से स्वतंत्र हो जाती हैं, क्योंकि नई ज़रूरत पर हमेशा नया एंडपॉइंट नहीं चाहिए।

GraphQL अपनी जटिलता भी लाता है। पूछताछ के प्रदर्शन का पूर्वानुमान कठिन है, क्योंकि क्या लोड होगा यह क्लाइंट तय करता है। N+1 समस्या — जहाँ नेस्टेड फ़ील्ड सुलझाने पर हर मूल रिकॉर्ड के लिए अलग डेटाबेस पूछताछ छिड़ती है — DataLoader जैसे समूहन-समाधान माँगती है। HTTP स्तर पर कैशिंग काम नहीं करती, क्योंकि हर पूछताछ एक ही POST एंडपॉइंट पर जाती है, इसलिए ऐप्लिकेशन-स्तर की कैशिंग रणनीतियाँ चाहिए। और रिज़ॉल्वर, म्यूटेशन, सब्सक्रिप्शन तथा इनपुट प्रकारों की सीखने की चढ़ाई REST के सीधे URL-और-क्रिया मॉडल से तीखी है।

GraphQL फ़्रंटएंड टीमों को बैकएंड बदलावों से आज़ादी देता है। पर वह आज़ादी इस ज़िम्मेदारी के साथ आती है कि आप हर उस पूछताछ का प्रदर्शन समझें जो आपका क्लाइंट सर्वर को भेजता है।

gRPC: HTTP/2 और Protobuf पर टिका उच्च-प्रदर्शन RPC

gRPC, जिसे मूलतः Google ने विकसित किया, एक और रास्ता लेता है। संसाधनों और पूछताछ के बजाय gRPC API को दूरस्थ प्रक्रिया-कॉल की तरह मॉडल करता है — आप विधियों वाली एक सेवा परिभाषित करते हैं, और क्लाइंट उन विधियों को स्थानीय फ़ंक्शन की तरह पुकारते हैं। मुख्य तकनीकी अंतर यह है कि gRPC क्रमबद्धता के लिए JSON के बजाय Protocol Buffers और परिवहन के लिए HTTP/1.1 के बजाय HTTP/2 उपयोग करता है।

syntax = "proto3";

service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc ListUsers (ListUsersRequest) returns (ListUsersResponse);
  rpc CreateUser (CreateUserRequest) returns (User);
  rpc StreamUserUpdates (StreamRequest) returns (stream UserUpdate);
}

message GetUserRequest {
  int32 id = 1;
}

message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
  Role role = 4;
  string created_at = 5;
}

enum Role { ADMIN = 0; USER = 1; }

message StreamRequest {}

message UserUpdate {
  User user = 1;
  string event_type = 2;
}

Protobuf एक सघन द्विआधारी प्रारूप में क्रमबद्ध करता है जो JSON से काफ़ी छोटा और पढ़ने में तेज़ है। HTTP/2 के बहुसंकेतन — एक ही कनेक्शन पर कई धाराएँ — के साथ मिलकर gRPC अधिक-मात्रा संवाद में REST या GraphQL की तुलना में नाटकीय रूप से कम विलंब और अधिक क्षमता देता है। इसी से gRPC माइक्रोसर्विस-से-माइक्रोसर्विस संवाद का प्रमुख विकल्प बनता है, जहाँ क्रमबद्धता का हर मिलीसेकंड और तार पर का हर बाइट मायने रखता है।

gRPC मूल रूप से चार तरह की धाराएँ भी देता है: इकहरी (एक अनुरोध, एक प्रतिक्रिया), सर्वर-धारा (एक अनुरोध, प्रतिक्रियाओं की धारा), क्लाइंट-धारा (अनुरोधों की धारा, एक प्रतिक्रिया) और द्विदिश धारा (दोनों ओर एक साथ)। इससे वह तीनों प्रोटोकॉल में वास्तविक-समय API के लिए सबसे मज़बूत विकल्प बन जाता है।

अदला-बदली यह है कि gRPC को ब्राउज़र से उपयोग करना कठिन है। ब्राउज़र क्लाइंट सीधे gRPC सेवाओं तक नहीं पहुँच सकते, क्योंकि उनके पास HTTP/2 फ़्रेम पर बारीक नियंत्रण नहीं होता। gRPC-Web एक उपाय के रूप में मौजूद है, पर जटिलता जोड़ता है। Protobuf संदेश तार पर मानव-पठनीय नहीं होते, जिससे समस्या-सुधार कठिन हो जाता है — ट्रैफ़िक देखने के लिए grpcurl या रिफ़्लेक्शन सेवा जैसे औज़ार चाहिए। और दस्तावेज़ीकरण की दुनिया OpenAPI या GraphQL के आत्म-निरीक्षण से कम परिपक्व है।

व्यावहारिक कसौटियों पर तुलना

REST, GraphQL और gRPC के बीच चुनाव शायद ही कभी विशुद्ध तकनीकी फ़ैसला होता है। सही चुनाव इस पर निर्भर है कि आपके क्लाइंट कौन हैं, उन्हें किस तरह का डेटा चाहिए, और आपके नेटवर्क तथा अवसंरचना की बाध्यताएँ क्या हैं। यहाँ हर प्रोटोकॉल की तुलना उन व्यावहारिक कसौटियों पर है जो प्रोडक्शन में सबसे ज़्यादा मायने रखती हैं।

API का संस्करण

REST संस्करण URL या Accept शीर्षक से संभालता है। /v1/users और /v2/users अनिश्चित काल तक साथ रह सकते हैं, जिससे क्लाइंट अपनी गति से खिसक सकते हैं। यह सरल और परखा हुआ है, पर दोहराव को बढ़ावा देता है — v2 अक्सर कुछ बदलावों के साथ v1 का अधिकांश तर्क दोहरा देता है। GraphQL स्कीमा को विकसित करके संस्करण से पूरी तरह बचता है। छोड़े जाने वाले फ़ील्ड @deprecated से चिह्नित होते हैं और तब तक स्कीमा में रहते हैं जब तक हर क्लाइंट न खिसक जाए। यह तब अच्छा चलता है जब सारे क्लाइंट आपके नियंत्रण में हों, पर सार्वजनिक API में घर्षण पैदा कर सकता है जहाँ क्लाइंट धीरे अद्यतन होते हैं। gRPC का protobuf स्कीमा डिज़ाइन से ही आगे-संगत है — आप मौजूदा क्लाइंट तोड़े बिना फ़ील्ड जोड़ सकते हैं, और छोड़े गए फ़ील्ड संक्रमण-अवधि के बाद हटाए जाते हैं। तीनों में यह सबसे सुघड़ रणनीति है, पर किसी फ़ील्ड का नाम बदलने या हटाने के लिए अनुशासन और एक निश्चित संक्रमण-अवधि चाहिए।

पृष्ठांकन के ढर्रे

REST में पृष्ठांकन आमतौर पर nextCursor फ़ील्ड के साथ कर्सर-आधारित होता है, या page और limit प्राचलों के साथ ऑफ़सेट-आधारित। सिद्धांत यह है कि प्रतिक्रिया में अगली कड़ी या टोकन हो और क्लाइंट उसका अनुसरण करे। GraphQL का पृष्ठांकन Relay Connection विनिर्देश उपयोग करता है, जो सूचियों को कर्सर और पृष्ठ-जानकारी के साथ किनारों में लपेटता है — अधिक शब्द-बहुल, पर तदर्थ REST तरीक़ों से अधिक सुसंगत। gRPC में पृष्ठांकन अनुरोध और प्रतिक्रिया संदेशों में हाथ से रखा जाता है, आमतौर पर page_token और page_size फ़ील्ड के साथ। कोई मानक नहीं है, पर protobuf स्कीमा अनुबंध को स्पष्ट रखता है।

  • REST: प्रतिक्रिया में nextCursor के साथ कर्सर-आधारित पृष्ठांकन प्रोडक्शन API के लिए अनुशंसित ढर्रा है।
  • GraphQL: Relay Connection विनिर्देश hasNextPage, hasPreviousPage और कर्सर के साथ एक मानकीकृत पृष्ठांकन मॉडल देता है।
  • gRPC: पृष्ठांकन आपके proto संदेशों में परिभाषित होता है; आम ढर्रा है अनुरोध में page_token और page_size तथा प्रतिक्रिया में next_page_token रखना।

प्रमाणीकरण और अधिकार

तीनों प्रोटोकॉल नीचे की परिवहन-सुरक्षा पर ही टिके हैं। REST आमतौर पर Authorization शीर्षक में बियरर टोकन उपयोग करता है। GraphQL वही ढर्रा अपनाता है — चूँकि सारे अनुरोध एक ही POST एंडपॉइंट से जाते हैं, टोकन GraphQL परत या मध्यवर्ती सॉफ़्टवेयर में जाँचा जाता है। gRPC हर कॉल में प्रमाणीकरण का मेटाडेटा जोड़ने के लिए इंटरसेप्टर उपयोग करता है, आमतौर पर gRPC मेटाडेटा शीर्षकों में JWT टोकन के रूप में। कोई भी प्रोटोकॉल किसी ख़ास प्रमाणीकरण विधि का आदेश नहीं देता — OAuth2, API कुंजियाँ या सत्र-आधारित प्रमाणीकरण चुनना API शैली से स्वतंत्र है।

दर-सीमा

दर-सीमा REST के साथ सबसे सरल है, क्योंकि हर एंडपॉइंट एक बँधी हुई क्रिया दर्शाता है। आप प्रति एंडपॉइंट प्रति क्लाइंट अनुरोध गिन सकते हैं और सीमा पार होने पर 429 लौटा सकते हैं। GraphQL इसे कठिन बनाता है, क्योंकि एक ही पूछताछ बहुत अलग मात्रा का काम छेड़ सकती है — एक फ़ील्ड की पूछताछ एक डेटाबेस खोज जितनी सस्ती हो सकती है, जबकि गहरे नेस्टेड संबंधों की पूछताछ कई गुना महँगी। इसलिए GraphQL API आमतौर पर लागत-आधारित दर-सीमा लगाते हैं, जहाँ हर फ़ील्ड का एक भार होता है और निष्पादन से पहले कुल लागत गिन ली जाती है। gRPC की दर-सीमा REST जैसी ही है, पर विधि के स्तर पर — आप प्रति क्लाइंट प्रति विधि RPC कॉल गिन सकते हैं, इस अतिरिक्त ध्यान के साथ कि धारा-कॉल अपनी पूरी अवधि तक संसाधन घेरती हैं, केवल शुरुआत में नहीं।

वास्तविक-समय API और धाराएँ

REST वास्तविक-समय अद्यतन WebSocket या Server-Sent Events से संभाल सकता है, पर ये दोनों REST विनिर्देश का हिस्सा नहीं — ये अलग प्रोटोकॉल हैं जो HTTP API के साथ जोड़े जाते हैं। GraphQL में सब्सक्रिप्शन हैं, जो विनिर्देश का प्रथम-श्रेणी हिस्सा हैं: क्लाइंट किसी घटना की सदस्यता लेता है और घटना होते ही WebSocket पर अद्यतन पाता है। gRPC के पास HTTP/2 पर मूल द्विदिश धाराओं के साथ सबसे मज़बूत कहानी है। एक ही gRPC कॉल दोनों दिशाओं में एक साथ डेटा बहा सकती है, जो वास्तविक-समय पटलों, चैट ऐप्लिकेशनों और घटना-चालित प्रणालियों के लिए आदर्श है। अगर वास्तविक-समय संवाद मुख्य ज़रूरत है, तो gRPC की धाराएँ सबसे परिपक्व और कुशल विकल्प हैं, उसके बाद GraphQL सब्सक्रिप्शन, और फिर REST प्लस WebSocket।

दस्तावेज़ीकरण और डेवलपर का अनुभव

REST के पास OpenAPI की बदौलत सबसे समृद्ध दस्तावेज़-दुनिया है। एक OpenAPI विनिर्देश हर एंडपॉइंट, अनुरोध-प्राचल, प्रतिक्रिया-स्कीमा और प्रमाणीकरण विधि को एक मशीन-पठनीय YAML या JSON फ़ाइल में लिख देता है। Swagger UI जैसे औज़ार उसे संवादात्मक दस्तावेज़-पृष्ठ में बदल देते हैं, और कोड-जनक दर्जनों भाषाओं के लिए क्लाइंट SDK बना देते हैं। इस परिपक्वता का अर्थ है कि नया डेवलपर विनिर्देश पढ़ने से लेकर पहली सफल API कॉल तक मिनटों में पहुँच सकता है।

GraphQL के पास आत्म-निरीक्षण है — एक अंतर्निहित तंत्र जिससे आप API का स्कीमा ही पूछ सकते हैं। GraphiQL और Apollo Studio Explorer जैसे औज़ार डेवलपरों को स्कीमा टटोलने, स्वतः-पूर्ति के साथ पूछताछ लिखने और अंतर्निहित दस्तावेज़ देखने देते हैं। उन डेवलपरों के लिए यह अच्छा अनुभव है जो पहले से जानते हैं कि आपका API मौजूद है, पर यह खोज-इंजन में मिलने या बाहरी API बाज़ारों में दिखने में उस तरह मदद नहीं करता जैसे OpenAPI विनिर्देश करता है।

gRPC proto फ़ाइलों को ही सत्य का स्रोत मानता है। proto फ़ाइल स्कीमा भी है और दस्तावेज़ भी। protoc-gen-doc जैसे औज़ार उनसे संदर्भ-दस्तावेज़ बना देते हैं, और gRPC रिफ़्लेक्शन क्लाइंट को सेवाएँ गतिशील रूप से खोजने देता है। gRPC का डेवलपर-अनुभव सुधर रहा है, पर औज़ारों की परिपक्वता में वह अब भी REST और GraphQL से पीछे है, ख़ासकर माइक्रोसर्विस की दुनिया के बाहर।

किसे कब उपयोग करें

REST सही विकल्प है जब आपका API बाहरी डेवलपर उपयोग करते हैं, जब आपको अधिकतम अंतर-प्रचालनीयता चाहिए, और जब आपके क्लाइंट को मानक HTTP कैशिंग चाहिए। यह सबसे सुरक्षित डिफ़ॉल्ट है क्योंकि हर भाषा, हर ढाँचा और हर प्रॉक्सी HTTP समझता है। अगर आप सार्वजनिक API बना रहे हैं, REST से शुरू करें।

GraphQL सही विकल्प है जब आपके API के कई तरह के क्लाइंट हों जिनकी डेटा-ज़रूरतें अलग हों, जब फ़्रंटएंड टीमों को बैकएंड बदलावों से स्वतंत्र चलना हो, और जब आप नेटवर्क अनुरोधों की संख्या घटाना चाहें। उपभोक्ता-केंद्रित ऐप्लिकेशनों में, जहाँ मोबाइल और वेब क्लाइंट को एक ही डेटा के अलग आकार चाहिए, यह उत्कृष्ट है।

gRPC आंतरिक माइक्रोसर्विस संवाद के लिए, उन उच्च-क्षमता प्रणालियों के लिए जहाँ क्रमबद्धता का ख़र्च मायने रखता है, और वास्तविक-समय धारा वाले ऐप्लिकेशनों के लिए सही विकल्प है। अगर आप ऐसी प्रणाली बना रहे हैं जहाँ दोनों छोर आपके नियंत्रण में हैं और प्रदर्शन मुख्य चिंता है, तो gRPC सबसे मज़बूत विकल्प है।

ये प्रोटोकॉल परस्पर अनन्य नहीं हैं। एक आम प्रोडक्शन वास्तुकला फ़ायरवॉल के पीछे सेवा-से-सेवा संवाद के लिए gRPC उपयोग करती है, एक GraphQL गेटवे खोलती है जो कई gRPC सेवाओं का डेटा जोड़ता है, और बाहरी क्लाइंट के लिए REST API देती है। सवाल यह नहीं कि हर जगह कौन-सा प्रोटोकॉल उपयोग करें — सवाल यह है कि आपकी प्रणाली के हर इंटरफ़ेस के लिए कौन-सा। हर एक के पीछे के डिज़ाइन-दर्शन को समझना ही आपको वह फ़ैसला सही लेने की क्षमता देता है।

See what your own repository can account for.

Thirty minutes on a repository you choose, including the part the record cannot attribute.
Book a demoSee the product