API Tester में नया क्या है: gRPC, Socket.IO, MQTT और असली test scripts
API Tester चार प्रोटोकॉल से बढ़कर सात हो गया है — server reflection के ज़रिए gRPC, Socket.IO और MQTT — और अपने पुराने नकली test evaluator की जगह एक असली sandboxed JavaScript इंजन ले आया है। साथ ही: संग्रह अब प्रोजेक्ट फ़ाइलों के रूप में version होते हैं, बिना किसी क्लाउड के।
जुलाई में हमने API Tester को IDE में बने एक पूरे REST, WebSocket, GraphQL और SSE क्लाइंट के रूप में पेश किया था। तब से इसे docs में एक पूरा विवरण मिला — और, इससे भी ज़्यादा ज़रूरी बात, तीन बिल्कुल नए प्रोटोकॉल, एक असली scripting इंजन, और अपने API संग्रहों को क्लाउड से पूरी तरह दूर रखने का एक तरीका।
यहाँ है वह सब कुछ जो नया है।
gRPC, server reflection के ज़रिए
API Tester अब एक भी .proto फ़ाइल माँगे बिना gRPC बोलता
है। host:port पर पॉइंट करें, Discover services टैप करें, और यह सर्वर
के reflection API को खंगालकर बताता है कि क्या कॉल किया जा सकता है — वही
तंत्र जिसे grpcurl और Postman का gRPC क्लाइंट इस्तेमाल करते हैं, इसलिए यह
किसी भी ऐसे सर्वर के विरुद्ध काम करता है जो reflection एक्सपोज़ करता है।
कॉल केवल unary होती हैं: streaming methods सूची में दिखते हैं, सही ढंग से
लेबल किए गए और disabled, न कि छुपाए गए या काम करने का दिखावा करते हुए। और
इंटरफ़ेस कभी भी आपसे किसी generated फ़ॉर्म को फ़ील्ड-दर-फ़ील्ड भरने को नहीं
कहता — आप plain JSON में अनुरोध लिखते हैं, PocketCode इसे अंदर ही अंदर एक
DynamicMessage में बना देता है, और आपको वापस JSON मिलता है।
Socket.IO, event दर event
MQTT की तरह Socket.IO में events की कोई तय सूची नहीं होती, इसलिए पैनल भी एक बनाने का दिखावा नहीं करता। एक namespace से कनेक्ट करें, चाहें तो auto-reconnect टॉगल करें, फिर:
- जिस भी event नाम की आपको उम्मीद हो, उसके लिए एक listener जोड़ें।
- JSON payload के साथ अपना खुद का एक event emit करें।
चैट-शैली लॉग में हर संदेश उसके संबंधित event के नाम के साथ चिह्नित होता है,
इसलिए message, typing और presence events को एक साथ संभालने वाला
connection भी पढ़ने लायक बना रहता है। नीचे आधिकारिक socket.io-client-java
है, इसलिए व्यवहार वैसा ही रहता है जैसा आपको किसी Node क्लाइंट से मिलता।
MQTT, topic दर topic
HiveMQ के क्लाइंट पर बनाया गया (यह MQTT 5 बोलता है, हालाँकि पैनल फ़िलहाल 3.1.1-स्तर की सुविधाएँ ही देता है — अभी तक कोई MQTT 5 properties नहीं, चुपचाप हटाने के बजाय दस्तावेज़ित)। TLS के साथ या बिना, username और password के साथ या बिना कनेक्ट करें, फिर:
- QoS 0, 1 या 2 के साथ किसी topic को subscribe करें।
- QoS और एक वैकल्पिक retain फ़्लैग के साथ किसी topic पर publish करें।
आने वाले संदेश topic के अनुसार समूहीकृत होते हैं, इसलिए sensors/+/temp पर
publish करने वाला एक डिवाइस एक अपठनीय स्ट्रीम में नहीं बदल जाता।
Test scripts जो असल में चलती हैं
यह वह है जिस पर हमें सबसे ज़्यादा गर्व है, क्योंकि यह उस चीज़ की जगह लेता है
जो असल में काम नहीं करती थी। पुराना test runner regular expression से
pm.test('...') कॉल को मिलाता था और test के नाम के शब्दों से परिणाम का
अंदाज़ा लगाता था — "user has admin role" नाम का एक test हमेशा पास होता था,
चाहे response में असल में कुछ भी हो।
वह ख़त्म हो गया। दो चीज़ें इसकी जगह लेती हैं:
- No-code assertions — एक फ़ील्ड चुनें (status code, response time, कोई header, body के अंदर एक JSONPath, body size), एक operator (equals, contains, greater/less than, exists), और एक value। कोई स्क्रिप्ट नहीं, हमेशा evaluate होता है, और फ़ोन के कीबोर्ड पर भी तेज़ी से बनाया जा सकता है।
- असली JavaScript test scripts, जो एक isolated sandbox प्रोसेस में
चलती हैं (
androidx.javascriptengine— APK में शून्य bytes जुड़ते हैं, क्योंकि यह डिवाइस के अपने WebView इंजन पर सवार होता है)। एक स्क्रिप्ट जो throw करती है वह ऐप को अपने साथ नहीं गिरा सकती। किसी दुर्लभ डिवाइस पर जहाँ आधुनिक WebView नहीं है, यह चुपचाप यह दिखावा करने के बजाय कि आपके tests पास हो गए, एक साधारण कंसोल चेतावनी में गिर जाता है।
दोनों अपने परिणाम उसी Tests टैब में लिखते हैं, और स्क्रिप्ट जो कुछ भी लॉग करती है वह एक समर्पित Console टैब में दिखता है — LOG / INFO / WARN / ERROR स्तर शामिल हैं।
संग्रह जो आपके repo में रहते हैं, किसी और के क्लाउड में नहीं
यह वह सुविधा है जो हमारे विचार से किसी और मोबाइल API क्लाइंट के पास नहीं है:
Save to project एक संग्रह को कोड एडिटर द्वारा पहले से खोले गए उसी
प्रोजेक्ट के अंदर, .pocketcode/api/<collection>/ के तहत, प्रति अनुरोध एक
पठनीय JSON फ़ाइल के रूप में मिरर करता है।
Room — PocketCode का लोकल डेटाबेस — रोज़मर्रा के लिए सत्य का स्रोत बना रहता है। Export करने पर Room से पूरी डायरेक्टरी फिर से बनती है, इसलिए यह हमेशा एक साफ़ स्नैपशॉट होता है। Import करने पर पहले एक पूर्वावलोकन दिखता है — एक बिल्कुल नया संग्रह, या ठीक कितने अनुरोध बदले जाएंगे — और डेटाबेस को कुछ भी तब तक नहीं छूता जब तक आप confirm न करें। फ़ाइलों को ऐप के अपने Git manager से commit करें और आपके API संग्रह की समीक्षा किसी भी अन्य pull request की तरह होती है, क्योंकि वह वही है।
कुछ छोटी चीज़ें जो मिलकर बड़ा फ़र्क़ बनाती हैं
- History को "Compare with…" मिला, दो responses के बीच एक असली diff — body पर line-by-line, साथ ही एक अलग header diff — और "Use as mock", जो किसी भी पुरानी response को एक टैप में mock route बना देता है।
- Runner अब एक CSV या JSON डेटा फ़ाइल पर iterate कर सकता है, हर iteration के लिए एक row, हर row Collection scope से ऊपर variable resolution में उपलब्ध होती है।
- Dynamic variables आ गए:
{{$guid}},{{$timestamp}},{{$isoTimestamp}},{{$randomInt}},{{$randomEmail}},{{$randomFirstName}},{{$randomLastName}}— वही shorthand जिसकी आपको Postman से उम्मीद होगी, हर उपयोग पर नए सिरे से resolve होता हुआ। - Mock Server अब एक आयातित OpenAPI दस्तावेज़ से सीधे routes जनरेट कर सकता है, और किसी भी History response को mock fixture के रूप में रिकॉर्ड कर सकता है।
सात प्रोटोकॉल, अंदाज़े की जगह असली scripts, और API संग्रह जो आपके बाक़ी कोड की तरह ही version होते हैं — यह सब अब भी पूरी तरह आपके फ़ोन पर चलता है, बिना क्लाउड में कुछ भी चाहे। अगर आपने इस मॉड्यूल का बाक़ी हिस्सा नहीं देखा, तो पूरा विवरण docs में है।
PocketCode Google Play की ओर बढ़ रहा है। अपने ख़ुद के डिवाइस पर इसे सबसे पहले आज़माने वालों में शामिल होने के लिए प्री-रजिस्ट्रेशन में शामिल हों।
API टेस्टर
इस पर त्वरित जवाब
PocketCode आज़माने के लिए तैयार हैं?
ऐप डाउनलोड करें और अपने फ़ोन से कोडिंग शुरू करें।