logo

Extra Block Types (EBT) - New Layout Builder experience❗

Extra Block Types (EBT) - styled, customizable block types: Slideshows, Tabs, Cards, Accordions and many others. Built-in settings for background, DOM Box, javascript plugins. Experience the future of layout building today.

Demo EBT modules Download EBT modules

❗Extra Paragraph Types (EPT) - New Paragraphs experience

Extra Paragraph Types (EPT) - analogical paragraph based set of modules.

Demo EPT modules Download EPT modules

Scroll
04/09/2025, by Ivan

JSON Drop API Documentation

TL;DR

यदि आपके पास ऐसा डेटा है जो एंटिटी-आधारित नहीं है और जिसे आप एक्सपोज़ करना चाहते हैं, तो REST चुनें। बाकी लगभग सभी मामलों में JSON:API चुनें।

थोड़ा और सूक्ष्म रूप में:

  • कोर का REST मॉड्यूल कुछ भी (कोई भी फ़ॉर्मैट, कोई भी लॉजिक, कोई भी HTTP मेथड) और अत्यधिक कॉन्फ़िगरेबिलिटी की अनुमति देता है। शक्तिशाली है लेकिन जटिल, इसलिए अपेक्षाकृत भंगुर (brittle) हो सकता है।
  • JSON:API Drupal की सबसे बड़ी ताकत (एंटिटीज़/डेटा मॉडलिंग) को एक सुसंगत तरीके से एक्सपोज़ करने पर केंद्रित है। सरल, फिर भी अधिकांश उपयोग मामलों के लिए पर्याप्त रूप से शक्तिशाली।

फ़ीचर मैट्रिक्स

JSON:API और REST के बीच उच्च-स्तरीय फीचर-आधारित तुलना।
फ़ीचर JSON:API REST टिप्पणी
एंटिटीज़ को संसाधन (resources) के रूप में एक्सपोज़ करना ✔️ ✔️ REST: प्रत्येक एंटिटी टाइप के लिए अलग से कॉन्फ़िगर करना पड़ता है। JSON:API: सब कुछ डिफ़ॉल्ट रूप से एक्सपोज़। दोनों: एंटिटी एक्सेस का सम्मान।
कस्टम डेटा को संसाधन के रूप में एक्सपोज़ करना   ✔️ कस्टम @RestResource प्लगइन्स लिखें। JSON:API केवल एंटिटीज़ को सपोर्ट करता है।
व्यक्तिगत संसाधन प्राप्त करना ✔️ ✔️  
संसाधनों की सूची प्राप्त करना ✔️ कुछ हद तक

REST: एक View कॉन्फ़िगर करनी होगी और "REST export" डिस्प्ले सेटअप करना होगा।

संसाधनों की सूची का पेजिनेशन ✔️ जैसे Pager Serializer जैसे अतिरिक्त मॉड्यूल्स की आवश्यकता REST: सपोर्टेड नहीं! REST एक्सपोर्ट व्यूज़ सभी संसाधन लौटाते हैं। 
संसाधनों की सूची को फ़िल्टर करना ✔️ कुछ हद तक

REST: तभी जब आप हर फ़ील्ड और हर संभावित ऑपरेटर के लिए एक exposed फ़िल्टर बनाते हैं

संसाधनों का सॉर्टिंग ✔️    
Includes/एम्बेडिंग ✔️ केवल HAL+JSON में  
फ़ील्ड वैल्यूज़ का अनावश्यक रैपिंग नहीं ✔️   HAL नॉर्मलाइज़ेशन और डिफ़ॉल्ट नॉर्मलाइज़ेशन (और इसलिए सभी फ़ॉर्मैट्स) Drupal के इन-मेमोरी PHP डेटा स्ट्रक्चर्स को ही एक्सपोज़ करते हैं, जिससे कंज्यूमर्स के लिए DX कठिन हो जाती है। JSON:API single-cardinality और single-property फ़ील्ड्स की नॉर्मलाइज़ेशन सरल बनाता है।
ऐसे फ़ील्ड छोड़ने की क्षमता जिनकी कंज्यूमर को ज़रूरत नहीं ✔️    
एकसमान URLs ✔️    
कंज्यूमर उपलब्ध resource types खोज सकता है ✔️    
Drupal-निर्पेक्ष (agnostic) response संरचना ✔️   REST: HAL नॉर्मलाइज़ेशन सैद्धांतिक रूप से Drupalisms से मुक्त है, पर व्यवहार में ऐसा नहीं है।
क्लाइंट लाइब्रेरीज़ ✔️    
विस्तार योग्य स्पेसिफ़िकेशन WIP    
शून्य कॉन्फ़िगरेशन ✔️   REST: प्रत्येक @RestResource प्लगइन परिभाषा एक्सपोज़ करने योग्य होती है, पर उसे एक्सपोज़ करने के लिए कॉन्फ़िगर करना पड़ता है। हर एक के लिए आपको अनुमत फ़ॉर्मैट्स, अनुमत ऑथेंटिकेशन प्रोवाइडर्स और विकल्पतः अनुमत HTTP मेथड्स चुनने पड़ते हैं।
JSON:API: सभी एंटिटीज़ स्वतः एक्सपोज़ होती हैं, एंटिटी/फ़ील्ड एक्सेस का सम्मान होता है, और इंस्टॉल किए गए सभी ऑथेंटिकेशन प्रोवाइडर्स स्वतः अनुमत होते हैं।

अधिक जानकारी

JSON:API मॉड्यूल को Drupal core में जोड़ने के औचित्य और मॉड्यूल आर्किटेक्चर के औचित्य देखें।

लेख स्रोत: Drupal Documentation.