gRPC, OpenAPI और REST को समझना और API डिज़ाइन में उनका उपयोग कब करें (2020)

 (cloud.google.com)
1 पॉइंट द्वारा GN⁺ 2025-01-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें

API प्रबंधन

gRPC और REST: API डिज़ाइन में gRPC, OpenAPI, REST को समझना और उनका उपयोग कब करें

  • API डिज़ाइन मॉडल: API डिज़ाइन में मुख्य रूप से RPC और REST, इन दो मॉडलों का उपयोग किया जाता है। अधिकांश आधुनिक API, HTTP प्रोटोकॉल के आधार पर लागू किए जाते हैं।
  • gRPC: HTTP 2.0 को ट्रांसपोर्ट प्रोटोकॉल के रूप में उपयोग करने वाली RPC API इम्प्लीमेंटेशन तकनीक। Google आदि में RPC और HTTP के विचारों को मिलाने वाले API का व्यापक उपयोग होता है।
  • HTTP के तीन प्रमुख उपयोग तरीके:
    1. REST: क्लाइंट सर्वर द्वारा दिए गए URL का जैसा है वैसा उपयोग करता है, और URL फ़ॉर्मेट को समझने की आवश्यकता नहीं होती।
    2. gRPC: HTTP/2 का उपयोग करता है, लेकिन HTTP API डिज़ाइनर के सामने प्रकट नहीं होता।
    3. OpenAPI: क्लाइंट URL path template का उपयोग करके API को कॉल करता है।

REST

  • विशेषताएँ: क्लाइंट को URL फ़ॉर्मेट समझने की आवश्यकता नहीं होती, और URL API स्पेसिफिकेशन का हिस्सा नहीं होता।
  • फायदे: इसमें स्थिरता, एकरूपता और सार्वभौमिकता जैसे वेब के लाभ मिलते हैं। entity-oriented model अधिक सरल और समझने में आसान होता है।

gRPC

  • विशेषताएँ: HTTP/2 का उपयोग होता है, लेकिन HTTP की बारीकियाँ छिपी रहती हैं। क्लाइंट procedures को कॉल करके और parameters पास करके API का उपयोग करता है।
  • फायदे: client-side programming libraries को आसानी से जनरेट किया जा सकता है, और performance अच्छा होता है।

OpenAPI

  • विशेषताएँ: API को कॉल करने के लिए URL path template का उपयोग किया जाता है, इसलिए क्लाइंट को URL फ़ॉर्मेट समझना होता है।
  • फायदे: केवल मानक HTTP तकनीकों से API तक पहुँचा जा सकता है। client-side programming libraries भी जनरेट की जा सकती हैं।

gRPC और OpenAPI की तुलना

  • समानताएँ: दोनों का उपयोग RPC interface definition language (IDL) के रूप में किया जा सकता है।
  • अंतर: gRPC, HTTP की बारीकियों को छिपाता है, जबकि OpenAPI, HTTP की बारीकियों को सामने लाता है।

REST के फायदे

  • entity-oriented model: यह अधिक सरल, समझने में आसान और समय के साथ अधिक स्थिर रहता है।

OpenAPI का उपयोग कैसे करें

  • path definition: paths और HTTP methods का उपयोग करके API को परिभाषित किया जाता है।

OpenAPI के फायदे और नुकसान

  • फायदे: यह RPC मॉडल के समान होने के कारण programmers के लिए परिचित है। इसे HTTP requests से मैप किया जा सकता है।
  • नुकसान: HTTP की बारीकियों को डिज़ाइन करने में काफी मेहनत लगती है।

gRPC के फायदे

  • सरल इम्प्लीमेंटेशन: server-side implementation सरल होता है, और client-side libraries आसानी से जनरेट की जा सकती हैं।
  • performance: binary payload का उपयोग होने से यह अधिक कुशल है।

gRPC के नुकसान

  • विशेष सॉफ़्टवेयर की आवश्यकता: क्लाइंट और सर्वर, दोनों को विशेष सॉफ़्टवेयर चाहिए।
  • proxy functionality की सीमा: HTTP API के विपरीत, proxy में functionality को बढ़ाना या बदलना कठिन होता है।

निष्कर्ष

  • API डिज़ाइन का चयन: REST, OpenAPI, gRPC — प्रत्येक के फायदे और नुकसान को ध्यान में रखकर चयन करना चाहिए।
  • gRPC उपयोग करते समय ध्यान देने योग्य बातें: जब क्लाइंट को gRPC तकनीक अपनाने की आवश्यकता न हो, और API आंतरिक हो, तब यह लाभदायक होता है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-24
Hacker News राय

  • इस बात का अफसोस है कि gRPC सीखा; debugging और configuration tuning में बहुत समय लगा

    • कहा जाता है कि gRPC अंदरूनी जटिलता छिपा देता है, लेकिन वास्तव में काफी debugging और configuration tuning की ज़रूरत पड़ती है
    • Maven plugin, HTTP2 compatibility issues, firewall issues आदि में बहुत समय बर्बाद हुआ
    • documentation कमजोर थी, और error messages को observable बनाना मुश्किल था

  • लंबे समय से API बनाते आए हैं, और gRPC तथा HTTP/REST दोनों का उपयोग किया है

    • OpenAPI और REST के अंतर को अलग से बताना अजीब लगता है
    • OpenAPI, HTTP API के व्यवहार को document करने का एक तरीका है, और यह RESTful API को व्यक्त कर सकता है
    • gRPC, protocol buffers का आदान-प्रदान करने वाला एक RPC mechanism है
    • gRPC efficient है, लेकिन HTTP libraries जितना शक्तिशाली नहीं है

  • FAANG में काम करने का अनुभव है, और लगता है कि internal service routing में gRPC उपयोगी है

    • RPC protocol बड़े पैमाने और high speed पर काम करना संभव बनाते हैं
    • लेकिन अगर target customer या web हो, तो gRPC का उपयोग नहीं करेंगे

  • जब तक bidirectional streaming नहीं करनी हो, gRPC समय की बर्बादी लगता है

    • अलग-अलग भाषाओं में implement की गई services के बीच RPC calls के लिए बहुत middleware चाहिए

  • gRPC का उपयोग करने वाले एक project में performance के कारण इसे अपनाया था, लेकिन बाद में JSON API पर switch किया

    • gRPC का अनुभव कम था, और project कई समस्याओं के कारण विफल हो गया

  • connectrpc का उपयोग करते हुए gRPC की समस्याओं को हल किया जा रहा है

    • buf.build के जरिए 3rd party proto files को आसानी से लाया जा सकता है
    • SDK auto-generation feature बहुत उपयोगी है

  • लगता है कि gRPC में development experience, REST से खराब है

    • अतिरिक्त tools की ज़रूरत पड़ती है, और generated client code जटिल होता है

  • Roy Fielding ने कहा कि REST API के लिए सिर्फ शुरुआती URI और standardized media types जानना पर्याप्त है

  • data center के भीतर gRPC का उपयोग पसंद नहीं है

    • performance बहुत ऊँची नहीं है, और open source clients की quality कम है
    • web-based API में JSON की readability पसंद है, लेकिन type mismatch की समस्या रहती है

  • लगा कि Google के बाहर gRPC तक पहुँचना कठिन है

    • gRPC JS client भारी और opaque है
    • REST की simplicity की तुलना में यह गलत दिशा में गया हुआ लगता है