मुख्य सामग्री पर जाएं
होम पर वापस
Feature

API Tester में नया क्या है: Socket.IO, MQTT और असली test scripts

API Tester अब छह प्रोटोकॉल बोलता है: Socket.IO और MQTT जुड़े, और test evaluator की जगह असली sandboxed JavaScript इंजन आया। साथ में संग्रह प्रोजेक्ट फ़ाइलों में।

अपडेट किया गया:
6 min
लेखक Pelayo Naredo
API Tester में नया क्या है: Socket.IO, MQTT और असली test scripts

जुलाई में हमने API Tester को IDE में बने REST, WebSocket, GraphQL और SSE क्लाइंट के रूप में पेश किया था। तब से इसे docs में एक पूरा विवरण मिला — और, इससे भी ज़्यादा ज़रूरी बात, दो नए प्रोटोकॉल, एक असली scripting इंजन, और अपने API संग्रहों को क्लाउड से पूरी तरह दूर रखने का एक तरीका।

यहाँ है वह सब कुछ जो नया है।

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 लाइब्रेरी है। custom headers, auth या query parameters नहीं हैं, और जोड़े गए listeners हटाए नहीं जा सकते।

MQTT, topic दर topic

HiveMQ के क्लाइंट पर बनाया गया, और यह केवल MQTT 5 बोलता है: जो broker सिर्फ़ 3.1.1 बोलता है वह कनेक्शन ठुकरा सकता है, और पैनल में अभी MQTT 5 properties नहीं हैं। TLS के साथ या बिना, username और password के साथ या बिना कनेक्ट करें, फिर:

  • QoS 0, 1 या 2 के साथ किसी topic को subscribe करें।
  • किसी QoS के साथ किसी topic पर publish करें (retain विकल्प नहीं है)।

आने वाले संदेश topic के अनुसार समूहीकृत होते हैं, इसलिए sensors/+/temp पर publish करने वाला एक डिवाइस एक अपठनीय स्ट्रीम में नहीं बदल जाता। unsubscribe, last will या अपना TLS certificate अभी नहीं है।

gRPC का क्या हुआ?

जब यह पोस्ट पहली बार छपी थी, तब इसमें एक प्रायोगिक gRPC पैनल की भी घोषणा थी। वह पैनल अब भी कोड में है, पर PocketCode का मौजूदा वर्शन उसे छिपा देता है: gRPC को एक ऐसी लाइब्रेरी चाहिए जिसे ऐप को बाहर रखना पड़ता है, इसलिए पैनल अभी Android पर काम नहीं कर सकता। जब तक वह काम नहीं करता, वह छिपा रहेगा। आज protocol menu में वे छह प्रोटोकॉल हैं जो काम करते हैं: REST, WebSocket, GraphQL, SSE, Socket.IO और MQTT।

Test scripts जो असल में चलती हैं

यह वह है जिस पर हमें सबसे ज़्यादा गर्व है, क्योंकि यह उस चीज़ की जगह लेता है जो असल में काम नहीं करती थी। पुराना test runner regular expression से pm.test('...') कॉल को मिलाता था और test के नाम के शब्दों से परिणाम का अंदाज़ा लगाता था — "user has admin role" नाम का एक test हमेशा पास होता था, चाहे response में असल में कुछ भी हो।

वह ख़त्म हो गया। दो चीज़ें इसकी जगह लेती हैं:

  1. No-code assertions — एक फ़ील्ड चुनें (status code, response time, कोई header, body के अंदर एक JSONPath, body size), एक operator (equals, contains, greater/less than, exists), और एक value। कोई स्क्रिप्ट नहीं, हमेशा evaluate होता है, और फ़ोन के कीबोर्ड पर भी तेज़ी से बनाया जा सकता है।
  2. असली JavaScript test scripts, जो एक isolated sandbox प्रोसेस में चलती हैं (androidx.javascriptengine, जो डिवाइस के अपने WebView इंजन पर सवार होता है)। एक स्क्रिप्ट जो throw करती है वह ऐप को अपने साथ नहीं गिरा सकती। किसी दुर्लभ डिवाइस पर जहाँ आधुनिक WebView नहीं है, यह चुपचाप यह दिखावा करने के बजाय कि आपके tests पास हो गए, एक साधारण कंसोल चेतावनी में गिर जाता है। स्क्रिप्ट को pm.* का एक छोटा हिस्सा मिलता है (pm.test, pm.expect, pm.environment, pm.response और कुछ और), पूरी Postman API नहीं।

दोनों अपने परिणाम उसी Tests टैब में लिखते हैं, और स्क्रिप्ट जो कुछ भी लॉग करती है वह एक समर्पित Console टैब में दिखता है — LOG / INFO / WARN / ERROR स्तर शामिल हैं।

संग्रह जो आपके repo में रहते हैं, किसी और के क्लाउड में नहीं

Save to project एक संग्रह को कोड एडिटर द्वारा पहले से खोले गए उसी प्रोजेक्ट के अंदर, .pocketcode/api/<collection>/ के तहत, प्रति अनुरोध एक पठनीय JSON फ़ाइल के रूप में मिरर करता है। आप इसे ख़ुद टैप करते हैं; कुछ भी अपने आप मिरर नहीं होता।

Room — PocketCode का लोकल डेटाबेस — रोज़मर्रा के लिए सत्य का स्रोत बना रहता है। Export करने पर Room से पूरी डायरेक्टरी फिर से बनती है, इसलिए यह हमेशा एक साफ़ स्नैपशॉट होता है। Import करने पर पहले एक पूर्वावलोकन दिखता है — एक बिल्कुल नया संग्रह, या ठीक कितने अनुरोध बदले जाएंगे — और डेटाबेस को कुछ भी तब तक नहीं छूता जब तक आप confirm न करें। फ़ाइलों को ऐप के अपने Git manager से commit करें और आपके API संग्रह की समीक्षा किसी भी अन्य pull request की तरह होती है, क्योंकि वह वही है। एक बात का ध्यान रखें: फ़ाइलों में auth values वैसी ही रहती हैं जैसी request में सेव हैं, इसलिए tokens को commit होने वाली चीज़ों से बाहर रखें।

कुछ छोटी चीज़ें जो मिलकर बड़ा फ़र्क़ बनाती हैं

  • History को "Compare with…" मिला, दो responses के बीच एक असली diff — body पर line-by-line, साथ ही एक अलग header diff — और "Use as mock", जो किसी पुरानी response को एक मेन्यू से mock route बना देता है।
  • Runner (Pro) अब एक CSV या JSON डेटा फ़ाइल पर iterate कर सकता है, हर iteration के लिए एक row, हर row Collection scope से ऊपर variable resolution में उपलब्ध होती है।
  • Dynamic variables आ गए: {{$guid}}, {{$timestamp}}, {{$isoTimestamp}}, {{$randomInt}}, {{$randomEmail}}, {{$randomFirstName}}, {{$randomLastName}}, हर उपयोग पर नए सिरे से resolve होते हुए।
  • Mock Server (Pro) अब एक आयातित OpenAPI दस्तावेज़ से सीधे routes जनरेट कर सकता है, और History की कोई response mock route बन सकती है।

छह प्रोटोकॉल, अंदाज़े की जगह असली scripts, और API संग्रह जो आपके बाक़ी कोड की तरह ही version होते हैं — यह सब आपके फ़ोन पर रहता है, बिना क्लाउड में कुछ भी चाहे। अगर आपने इस मॉड्यूल का बाक़ी हिस्सा नहीं देखा, तो पूरा विवरण docs में है।

PocketCode Google Play पर उपलब्ध है। इसे अपने डिवाइस पर आज़माने के लिए PocketCode पाएँ।

इस लेख के पीछे का टूल

API टेस्टर

PocketCode आज़माने के लिए तैयार हैं?

ऐप डाउनलोड करें और अपने फ़ोन से कोडिंग शुरू करें।