cURL कमांड बिल्डर — बिना अंदाज़े के सही HTTP रिक्वेस्ट बनाएं
curl कमांड बिल्डर
प्रमाणीकरण
हेडर
रिक्वेस्ट बॉडी
curl \ -H 'Accept: application/json' \ 'https://api.example.com/v1/items?page=2'
यह कमांड आपके ब्राउज़र में ही बनाया जाता है और कहीं नहीं भेजा जाता। जिन मानों में रिक्त स्थान या शेल मेटा-वर्ण हों, उन्हें एकल उद्धरण चिह्नों में रखा जाता है ताकि कमांड ज्यों का त्यों सुरक्षित चले; किसी मान के भीतर आया सीधा उद्धरण चिह्न POSIX के तरीके से एस्केप किया जाता है।
क्या है
curl यानी client URL एक कमांड-लाइन प्रोग्राम है जो URL सिंटैक्स की मदद से सर्वर से डेटा भेजता और लाता है। यह macOS में पहले से इंस्टॉल रहता है, Git for Windows के बेस इंस्टॉल में आ जाता है, और लगभग हर CI रनर, कंटेनर इमेज और रिमोट शेल में मौजूद होता है। 1998 में यह टर्मिनल से वेब पेज खींचने के लिए बना था और धीरे-धीरे सार्वभौमिक HTTP क्लाइंट बन गया: HTTP/1.1 और HTTP/2, HTTPS, प्रॉक्सी, कुकीज़, रीडायरेक्ट, साथ में FTP और SFTP। हर cURL कमांड एक ही तरह पढ़ा जाता है, क्योंकि हर फ़्लैग रिक्वेस्ट के एक हिस्से से जुड़ा होता है: - मेथड फ़्लैग। -X के बाद आने वाला क्रिया शब्द HTTP मेथड तय करता है। GET में — curl का डिफ़ॉल्ट — यह फ़्लैग पूरी तरह छोड़ा जा सकता है, क्योंकि सिर्फ़ curl और URL लिखकर ही GET हो जाता है, और HEAD के साथ भी यही बात है। POST, PUT, PATCH, DELETE और OPTIONS के लिए यह फ़्लैग ही सर्वर को बताता है कि आप करना क्या चाहते हैं। - हेडर फ़्लैग। हर -H 'नाम: मान' जोड़ी एक HTTP हेडर जोड़ती है। Accept बताता है कि आप कौन-सा फ़ॉर्मैट वापस चाहते हैं, Content-Type आपके भेजे जा रहे बॉडी को बताता है, और बाकी नाम ज्यों के त्यों पहुंच जाते हैं। प्रोटोकॉल में हेडर के नाम में केस का फ़र्क़ नहीं पड़ता। - ऑथ फ़्लैग। -u 'यूज़र:पासवर्ड' HTTP Basic ऑथेंटिकेशन करता है, यानी curl खुद यूज़र-पासवर्ड को बेस 64 में एनकोड करके Authorization हेडर में भर देता है। बेयरर टोकन का कोई ख़ास फ़्लैग नहीं होता, वह -H 'Authorization: Bearer ...' से भेजा जाता है। यह अंतर समझना ज़रूरी है क्योंकि -u किसी दूसरी क्रेडेंशियल प्रणाली का शॉर्टहैंड नहीं, बल्कि एक ही ख़ास हेडर का शॉर्टहैंड है — वही Authorization हेडर हाथ से लिखने से बिल्कुल एक जैसा रिक्वेस्ट बनता है। - डेटा फ़्लैग। -d, --data और --data-raw तीनों बॉडी जोड़ते हैं, और --data-urlencode एक name=valor जोड़ी को प्रतिशत-एनकोड करता है। एक बारीक बात बहुत लोगों को चौंका देती है: कोई भी डेटा फ़्लैग जोड़ते ही curl मेथड को POST कर देता है, जब तक आप खुद -X न लिखें। इसलिए बॉडी के साथ भेजा गया PUT चुपचाप अपडेट नहीं, नया रिकॉर्ड बना सकता है। यह बिल्डर उस नियम को छिपाए नहीं, दिखाता है — जब तक मेथड GET है और आप बॉडी चुन लेते हैं, -X POST अपने आप प्रकट हो जाता है। - URL। सबसे आख़िर में आता है, साफ़ हो तो बिना कोट, और query string हो तो कोट के भीतर। हाथ से लिखे गए कमांड ज़्यादातर यहीं टूटते हैं। शेल curl को देखने से पहले ही लाइन को पढ़ता है, और स्पेस, &, |, ;, $, >, *, ?, कोष्ठक, सिंगल और डबल कोट को डेटा नहीं बल्कि वाक्य-विचार मानता है। https://api.example.com/search?q=a&b=2 को सीधे चिपकाया जाए तो वह & पर कट जाती है: curl सिर्फ़ /search?q=a मांगता है और शेल बचे हुए b=2 को चलाने की कोशिश करता है, जिससे एक ऐसा एरर आता है जिसका API से कोई लेना-देना नहीं। JSON बॉडी का भी यही हाल है, क्योंकि braces के भीतर के स्पेस उसे कई हिस्सों में बाँट देते हैं। वैल्यू को सिंगल कोट में लपेटने का अर्थ ही यह है कि शेल उसे ज्यों का त्यों सौंप दे। सिंगल कोट सबसे सुरक्षित आवरण है क्योंकि उसके भीतर कुछ भी व्याख्यायित नहीं होता: न डॉलर चिन्ह, न बैकटिक, न दूसरा कोट। इकलौती समस्या यह है कि जिस वैल्यू के भीतर खुद सिंगल कोट हो, उसे सिंगल कोट के भीतर एस्केप नहीं किया जा सकता। POSIX इसे इस तरह सुलझाता है: कोट बंद करें, बैकस्लैश से एस्केप किया गया कोट डालें, और कोट फिर खोल दें — यही रूप यह बिल्डर किसी हेडर वैल्यू या पासवर्ड में apostrophe मिलते ही अपने आप बना देता है। जब कोई कमांड बिना निगरानी के चलता है, तब एक और बात अहम है: idempotency। GET, HEAD, PUT और DELETE परिभाषा के अनुसार idempotent हैं, यानी वही रिक्वेस्ट दोबारा भेजने पर सर्वर की अवस्था उतनी ही रहती है जितनी एक बार भेजने पर, इसलिए नेटवर्क रीट्राई हानिरहत है। POST ऐसा नहीं है: रीट्राई होने पर दो रिकॉर्ड बन सकते हैं या कार्ड से दो बार पैसे कट सकते हैं। इसीलिए curl डिफ़ॉल्ट रूप से केवल idempotent मेथड ही रीट्राई करता है, और इसी वजह से मिश्रित verbs वाली स्क्रिप्ट में --retry आम तौर पर सुरक्षित रहता है। आख़िर यह भी देख लीजिए कि आउटपुट को कैसे पढ़ें। डिफ़ॉल्ट रूप से curl स्टैंडर्ड एरर पर एक प्रोग्रेस मीटर बनाता है जिसमें प्रतिशत, डाउनलोड और कुल बाइट्स, वर्तमान गति और अनुमानित शेष समय दिखता है; आउटपुट को pipe या redirect करते ही यह गायब हो जाता है, और --silent इसे पूरी तरह बंद कर देता है। -v पूरा संवाद छापता है, जहाँ < से curl द्वारा भेजा गया और > से प्राप्त हुआ दिखता है — रिक्वेस्ट लाइन, हर भेजा गया हेडर, रिस्पॉन्स स्टेटस लाइन और हर मिला हेडर। -i रिस्पॉन्स हेडर को body में ही रहने देता है बजाय छिपाए, और --fail के साथ curl 4xx या 5xx पर गैर-शून्य exit code देता है, जो स्क्रिप्ट के लिए बिल्कुल सही व्यवहार है।
कैसे उपयोग करें
- Method ड्रॉपडाउन में वह verb चुनिए जिसकी आपके endpoint को ज़रूरत है — GET, POST, PUT, PATCH, DELETE, HEAD या OPTIONS। नीचे बना कमांड अपने आप बदलता रहता है, और GET व HEAD में -X जानबूझकर नहीं जोड़ा जाता।
- पूरा URL URL फ़ील्ड में चिपकाइए, स्कीम और query string दोनों सहित, जैसे https://api.example.com/v1/items?page=2।
- Authentication में None, Basic या Bearer पर क्लिक कीजिए। Basic चुनने पर Username और Password के फ़ील्ड दिखेंगे और -u बनेगा; Bearer चुनने पर एक टोकन फ़ील्ड दिखेगा और Authorization हेडर आपके लिए बन जाएगा।
- Headers वाले हिस्से में काम कीजिए: किसी पंक्ति को शामिल करने या हटाने के लिए उसकी चेकबॉक्स टिक कीजिए, Header name और Header value भरिए, अनावश्यक पंक्ति हटाने के लिए × बटन दबाइए, या नई पंक्ति जोड़ने के लिए + Add header।
- Request body में No body, JSON, Form fields या Raw text चुनिए। JSON और Form fields अपने आप मिलता हुआ Content-Type जोड़ देते हैं, जब तक आपने खुद कोई Content-Type हेडर न लिखी हो।
- JSON में Pretty-print को टिक कीजिए तो बॉडी दोबारा इंडेंट के साथ लिखी जाएगी, और न टिक किया हो तो आपका लिखा हुआ टेक्स्ट ज्यों का त्यों रहता है। Form fields हर name=value पंक्ति को अलग --data-urlencode फ़्लैग में बदल देता है।
- Command ब्लॉक में बना हुआ पूरा कमांट देखिए और Copy बटन दबाकर एक-पंक्ति वाला संस्करण क्लिपबोर्ड पर लीजिए। असेंबलिंग ब्राउज़र में होती है, इसलिए कमांड में मौजूद पासवर्ड या टोकन कहीं नहीं भेजा जाता।
उदाहरण
इनपुट: GET https://api.example.com/v1/items?page=2, हेडर Accept: application/json
प्रक्रिया:
GET curl का डिफ़ॉल्ट मेथड है इसलिए -X छोड़ा जाता है, हेडर -H से निकलता है, URL में query string बनी रहती हैपरिणाम: curl \
-H 'Accept: application/json' \
https://api.example.com/v1/items?page=2
इनपुट: POST https://api.example.com/v1/items, JSON बॉडी {"name":"example","active":true} और Bearer टोकन
प्रक्रिया:
JSON बॉडी से -X POST और Content-Type बनते हैं, टोकन Authorization हेडर बन जाता है, पूरा पेलोड सिंगल कोट में रहता हैपरिणाम: curl \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer eyJhbGciOi...' \
--data-raw '{
"name": "example",
"active": true
}' \
https://api.example.com/v1/items
इनपुट: POST https://api.example.com/login, Form fields name=ada&password=secret, Basic ऑथ ada:hunter2
प्रक्रिया:
Basic ऑथ -u बन जाता है, हर फ़ॉर्म जोड़ी अपना --data-urlencode फ़्लैग बनाती है, urlencoded Content-Type जुड़ जाता हैपरिणाम: curl \
-H 'Content-Type: application/x-www-form-urlencoded' \
-u 'ada:hunter2' \
--data-urlencode 'name=ada' \
--data-urlencode 'password=secret' \
https://api.example.com/login
इनपुट: DELETE https://api.example.com/v1/items/42, कस्टम हेडर X-Request-Id: 8f14e45f
प्रक्रिया:
DELETE में बॉडी नहीं होता इसलिए -X DELETE साफ़ लिखा जाता है, कस्टम हेडर कोट में रहता है, कुछ भी ऐसा नहीं जोड़ा जाता जो आपने न कहा होपरिणाम: curl \
-X DELETE \
-H 'X-Request-Id: 8f14e45f' \
https://api.example.com/v1/items/42
संबंधित खोजें
लोग यह भी खोजते हैं: curl कमांड बनाना, curl कमांड जनरेटर, curl कमांड ऑनलाइन, curl में हेडर कैसे लगाएं, curl basic authentication, curl bearer token।
curl कमांड बनानाcurl कमांड जनरेटरcurl कमांड ऑनलाइनcurl में हेडर कैसे लगाएंcurl basic authenticationcurl bearer tokencurl से json भेजेंcurl फ़ॉर्म डेटाcurl कमांड उदाहरणशेल कोटिंग सीखेंhttp रिक्वेस्ट कमांडrest api टेस्टिंगapi डीबग करने का टूलफ़्री ऑनलाइन डेवलपर टूलटर्मिनल http क्लाइंटcurl सिंटैक्स हेल्परवेब डेवलपर टूलकमांड जनरेटर
अक्सर पूछे जाने वाले प्रश्न
GET रिक्वेस्ट में -X क्यों नहीं जोड़ा जाता?
क्योंकि बिना किसी फ़्लैग के सिर्फ़ curl और URL पहले ही GET कर देता है, इसलिए वह फ़्लैग शुद्ध शोर होगा। HEAD के साथ भी यही तर्क लागू होता है, क्योंकि वह सिर्फ़ हेडर माँगता है। POST, PUT, PATCH, DELETE और OPTIONS में मेथड बताना ज़रूरी है, इसलिए वहाँ फ़्लैग जोड़ा जाता है। अगर किसी अजीब endpoint से बात करनी पड़े जो असामान्य verb माँगता है, तो आप खुद कोई कस्टम हेडर पंक्ति जोड़ दीजिए, वह भी कमांड में आ जाएगा।
-u फ़्लैग इस्तेमाल करूँ या Authorization हेडर खुद लिखूँ?
दोनों एक जैसा रिक्वेस्ट बनाते हैं। -u 'यूज़र:पासवर्ड' एक शॉर्टहैंड है जो जोड़ी को बेस 64 में एनकोड करके Authorization: Basic हेडर भेजता है, जिससे वह एनकोडिंग खुद करने की ज़रूरत नहीं पड़ती। हाथ से हेडर लिखना तभी बेहतर है जब ऑथ स्कीम कस्टम हो, जब टोकन में ऐसे अक्षर हों जिन्हें कमांड लाइन पर टाइप करने से बचना चाहते हों, या जब पासवर्ड में खुद colon हो — क्योंकि पहले colon के बाद का सारा हिस्सा पासवर्ड माना जाता है, और यह बात बार-बार लोगों को चकका देती है।
JSON बॉडी को सिंगल कोट में क्यों रखना पड़ता है?
क्योंकि शेल पूरी कमांड लाइन को curl तक पहुँचने से पहले ही पढ़ लेता है, और बिना कोट वाला JSON पूरा स्पेस, curly braces, कोट और colon से भरा होता है जिन्हें शेल वाक्य-विचार मानता है। कोट के बिना बॉडी कई अलग-अलग आर्ग्युमेंट में बँट जाती है और curl एक उलझा हुआ डेटा-मिसिंग एरर दिखाता है। सिंगल कोट के भीतर हर अक्षर यथावत पहुँचता है, JSON की अपनी डबल कोट समेत। यह बिल्डर हर ऐसे वैल्यू को कोट दे देता है जो शुद्ध अक्षर-अंक-सुरक्षित नहीं है, इसलिए कमांड ज्यों का त्यों चलेगा।
क्या यह मेरे लिए Content-Type हेडर खुद जोड़ता है?
हाँ, पर सिर्फ तभी जब आपने खुद कोई Content-Type न दी हो। JSON बॉडी चुनने पर Content-Type: application/json जुड़ता है, और Form fields चुनने पर Content-Type: application/x-www-form-urlencoded। यदि हेडर सूची में पहले से Content-Type मौजूद है, तो यह अपनी अलग नहीं लगाता, ताकि वही हेडर दो बार अलग-अलग मान के साथ न जाए। बिना Content-Type के JSON भेजना 400 एरर का एक आम कारण है: सर्वर मान लेता है कि यह फ़ॉर्म एनकोडिंग है और आपकी बॉडी पढ़ नहीं पाता।
क्या यहाँ असली बेयरर टोकन या पासवर्ड डालना सुरक्षित है?
भेजे जाने के मामले में हाँ। कमांड आपके ब्राउज़र टैब में चलने वाला JavaScript बनाता है, इसलिए URL, क्रेडेंशियल और हेडर कभी आपकी मशीन से बाहर नहीं जाते और हमारे सर्वर तक नहीं पहुँचते। कुछ भी स्टोर नहीं होता, कोई लॉग नहीं बनता, और टैब बंद करते ही सब गायब हो जाता है। फिर भी सामान्य सतर्कता रखिए: किसी भी वेब पेज में टाइप किया टोकन ब्राउज़र एक्सटेंशन के कारण उजागर हो सकता है, और शेल में चिपकाया गया कमांड आपके शेल हिस्ट्री में रह जाता है, इसलिए साझा की गई डॉक्यूमेंटेशन में प्लेसहोल्डर वैल्यू रखिए।
JSON के बजाय फ़ॉर्म डेटा कैसे भेजें?
Request body में Form fields चुनिए और हर लाइन में एक name=value लिखिए; सब एक ही लाइन में ampersand से जोड़कर भी लिखा जा सकता है, क्योंकि टूल उसे अलग कर देता है। हर जोड़ी अपना --data-urlencode 'नाम=मान' फ़्लैग बन जाती है और Content-Type स्वतः application/x-www-form-urlencoded सेट हो जाता है। जिस मान में reserved अक्षर हों, उसमें कच्चा ampersand डालने के बजाय प्रतिशत एनकोडिंग का उपयोग कीजिए, वरना सर्वर को फ़ील्ड कटा हुआ मिलेगा।
बॉडी जोड़ते ही मेथड POST क्यों हो जाता है?
यह curl का अपना व्यवहार है: जब आप -d या --data-raw से डेटा जोड़ते हैं और मेथड नहीं लिखते, तो curl POST मान लेता है। यह बिल्डर उसे चुपचाप नहीं करता बल्कि साफ दिखाता है, इसलिए अगर मेथड ड्रॉपडाउन अब भी GET पर है और आपने बॉडी जोड़ दी, तो -X POST दिखाई देगा। पहले ड्रॉपडाउन में असली मेथड चुन लीजिए, वरना अपडेट करने के इरादे से भेजा गया रिक्वेस्ट चुपचाप नया रिकॉर्ड बना देगा।