API கோரிக்கைகளில் தேர்ச்சி பெறுதல்: டெவலப்பர்களுக்கான கர்ல் (Curl) பயன்படுத்துவதற்கான ஒரு நடைமுறை வழிகாட்டி

API கோரிக்கைகளில் தேர்ச்சி பெறுதல்: டெவலப்பர்களுக்கான கர்ல் (Curl) பயன்படுத்துவதற்கான ஒரு நடைமுறை வழிகாட்டி

பெரும்பாலான API பிழைதிருத்தங்கள், யாராவது ஒருவர் ஒரு cURL கட்டளையை ஸ்லாக்கில் பதிவிட்டு, “இது என் கணினியில் வேலை செய்கிறது” என்று சொல்வதிலிருந்துதான் தொடங்குகின்றன. இந்தக் கட்டத்தில் இது அடிப்படையில் டெவலப்பர்களின் ஒரு வழக்கமான கூற்றாகிவிட்டது. cURL அற்புதமாக நேரடியானது: ஒரு கோரிக்கையை அனுப்புங்கள், பதிலைப் பாருங்கள், அடுத்த வேலைக்குச் செல்லுங்கள். ஆனால், ஒரு சிறிய விஷயத்தில் தவறு செய்துவிட்டு, பின்னர் அரை மணி நேரம் API, அங்கீகார சேவையகம், கேட்வே, நெட்வொர்க் அல்லது உண்மையாகச் சொன்னால் நிலாவைக் கூட குறை சொல்வதும் மிகவும் எளிது.

இந்த மிகவும் சாதாரணமான காட்சியைக் கற்பனை செய்து பாருங்கள். மாயா ஒரு சிறிய முன்பதிவு செயலியில் ஒரு கட்டணச் சேவை வழங்குநரை ஒருங்கிணைக்கிறார். அந்த எண்ட்பாயிண்ட் ஒரு நேர்த்தியான JSON பதிலை வழங்கும் என்று ஆவணங்கள் கூறுகின்றன, ஆனால் அவரது டெர்மினல் தொடர்ந்து '401 அங்கீகரிக்கப்படாதது' (401 Unauthorized ) என்று காட்டுகிறது. அவர் டோக்கனை மீண்டும் உருவாக்குகிறார். அதே நிலைதான். அவர் தனது சக ஊழியரிடம் கேட்கிறார், அவர் அந்த அங்கீகாரத் தலைப்பில் (Authorization header) ஸ்மார்ட் கோட்ஸ் இருப்பதைக் கவனிக்கிறார், ஏனெனில் அது ஒரு குறிப்பு எடுக்கும் செயலி மூலம் நகலெடுக்கப்பட்டுள்ளது. அந்த இரண்டு சுருண்ட சிறிய மேற்கோள் குறிகள் 25 நிமிடங்களை வீணடித்துவிட்டன. இதில் யாருக்கும் பெருமையில்லை, இதை எல்லோரும் செய்திருக்கிறார்கள்.

குறிப்பாக, உண்மையான திட்டப் பணிகளின் அழுத்தத்தின் கீழ் API-களைச் சோதிக்கும்போது மீண்டும் மீண்டும் தோன்றும் cURL தவறுகள் இதோ.

1. நகலெடுக்கப்பட்ட கட்டளைகளை அதிகமாக நம்புவது

ஆவணங்களிலிருந்து cURL எடுத்துக்காட்டுகளை நகலெடுப்பது இயல்பானது. விசித்திரமான சிக்கல்கள் நுழைவதும் இங்குதான். ஆவணப் பக்கங்கள், அரட்டைச் செயலிகள், PDFகள், டிக்கெட்டுகள் மற்றும் ரிச்-டெக்ஸ்ட் எடிட்டர்கள் ஆகியவை சாதாரண எழுத்துக்களை "அழகான" எழுத்துக்களாக மாற்றக்கூடும். நேரான மேற்கோள் குறிகள் வளைந்த மேற்கோள் குறிகளாக மாறும். நீண்ட கோடுகள் எம் டேஷ்களாக மாறும். வரி முறிவுகள் மறைந்துவிடும். ஒரு வரியின் முடிவில் உள்ள பின்சாய்வுக் கோடு மறைந்துவிடும், திடீரென்று இரண்டு ஆர்கியுமென்ட்கள் ஒரே குழப்பமான கோப்பாக மாறிவிடும்.

ஒரு கட்டளை பார்ப்பதற்குச் சரியாகத் தெரிந்தாலும், அது தவறாகச் செயல்பட்டால், முதலில் அதை ஒரு சாதாரண உரைத் திருத்தியில் (plain text editor) ஒட்டவும். சொல் செயலாக்கியில் (word processor) அல்ல. சாதாரண உரையில். மேற்கோள் குறிகள், கோடுகள் மற்றும் வரித் தொடர்ச்சிகளைச் சரிபார்க்கவும். macOS மற்றும் Linux ஷெல்களில், மேற்கோள் குறிகள் மிகவும் முக்கியமானவை. Windows PowerShell-இல், அவை வேறுவிதமாக முக்கியத்துவம் பெறுகின்றன, ஏனெனில் நிச்சயமாக அவை முக்கியமானவைதான்.

2. ஷெல்களைக் குழப்பிக்கொண்டு, ஒரே கட்டளை எல்லா இடங்களிலும் செயல்படும் என்று எதிர்பார்ப்பது.

Bash-க்காக எழுதப்பட்ட ஒரு cURL கட்டளை, PowerShell அல்லது Windows Command Prompt-இல் அப்படியே செயல்படாமல் போகலாம். HTTP கோரிக்கை கருத்தியல் ரீதியாக ஒரே மாதிரியாக இருக்கலாம், ஆனால் cURL உங்கள் உரையைப் பார்க்கும் முன்பே, ஷெல் அதை அலசி ஆராய்ந்துவிடுகிறது. இதன் பொருள், மேற்கோள் குறிகள், எஸ்கேப்பிங், சூழல் மாறிகள் மற்றும் வரித் தொடர்ச்சி விதிகள் ஆகியவை முடிவை மாற்றக்கூடும்.

உதாரணமாக, Bash ஒரு கட்டளையை வரிகளுக்கிடையே பிரிக்க பொதுவாக ஒரு பின்சாய்வுக் கோட்டைப் (backslash) பயன்படுத்துகிறது. PowerShell ஒரு பின்குறியைப் (backtick) பயன்படுத்துகிறது. Bash-ல் இரட்டை மேற்கோள் குறிகளுடன் கூடிய JSON தரவுகள் பொதுவாக ஒற்றை மேற்கோள் குறிகளில் வசதியாக இருக்கும், ஆனால் ஒற்றை மேற்கோள் குறிகள் எல்லாச் சூழல்களிலும் ஒரே மாதிரி செயல்படுவதில்லை. எனவே, API ஒரு பிரச்சனையாக இல்லாமல் இருக்கலாம். ஒரு உதவாத உதவியாளரைப் போல, ஷெல் உங்கள் கோரிக்கையை அமைதியாக மறுசீரமைத்துக் கொண்டிருக்கலாம்.

ஒரு நடைமுறைப் பழக்கம்: சக குழுவினருடன் கட்டளைகளைப் பகிரும்போது, அது எந்த ஷெல்லில் சோதிக்கப்பட்டது என்பதைக் குறிப்பிடவும். “இதை முயற்சித்துப் பாருங்கள்” என்பதை விட, “பாஷில் வேலை செய்கிறது” என்று கூறுவது அதிகப் பயனுள்ளது.

3. Content-Type ஹெடரை மறந்துவிடுதல்

இது மிகவும் சாதாரணமாக நடப்பதால், இதற்கென்று ஒரு சிறிய பித்தளைப் பட்டயம் வைக்கவே தகுதியானது. நீங்கள் உள்ளடக்கத்தில் JSON-ஐ அனுப்புகிறீர்கள், ஆனால் அது JSON என்பதை சேவையகத்திற்குச் சொல்ல மறந்துவிடுகிறீர்கள். சில API-கள் அதை ஊகித்துக்கொள்கின்றன. சில ஊகிப்பதில்லை. சில, பயனுள்ள 415 அல்லது 400 பிழையைத் திருப்பி அனுப்புகின்றன. சிலவோ, தெளிவற்ற மற்றும் எரிச்சலூட்டும் ஒன்றைச் செய்கின்றன.

நீங்கள் JSON அனுப்பினால், பின்வரும் ஹெடரைச் சேர்க்கவும்:

உள்ளடக்க வகை: application/json

மேலும், நீங்கள் JSON-ஐ திரும்பப் பெறுவீர்கள் என எதிர்பார்த்தால், பின்வருவனவற்றைச் சேர்ப்பதும் உதவியாக இருக்கும்:

ஏற்றுக்கொள்: application/json

இது எப்போதும் அவசியமில்லை, ஆனால் இது தெளிவின்மையை நீக்குகிறது. நீங்கள் வெளிப்படையாகக் குறிப்பிடும்போது, அது மீண்டும் மீண்டும் செய்வது போல் தோன்றினாலும், API-களில் உள்ள பிழைகளைச் சரிசெய்வது மிகவும் எளிதாகிறது.

4. சேமிக்கப்படும் கட்டளைகளில் இரகசியங்களை நேரடியாக வைப்பது

டோக்கன்கள், API விசைகள், செஷன் குக்கீகள், கிளையன்ட் இரகசியங்கள். நீங்கள் கவனக்குறைவாக இருந்தால், ஷெல் வரலாறு, டெர்மினல் பதிவுகள், CI பதிவுகள், ஸ்கிரீன்ஷாட்கள், ஆதரவு டிக்கெட்டுகள், பகிரப்பட்ட ஆவணங்கள் என இவை எல்லா இடங்களிலும் சென்று சேரும். ஒரு cURL கட்டளை என்பது வெறும் ஒரு சோதனைக் கோரிக்கை மட்டுமல்ல, அது எளிதில் எடுத்துச் செல்லக்கூடிய ஒரு சிறிய கசிவாகவும் மாறக்கூடும்.

முடிந்தவரை சூழல் மாறிகளைப் பயன்படுத்துங்கள். அங்கீகாரத் தலைப்பு (Authorization header) போன்ற ஒன்று, டோக்கனை அப்படியே ஒட்டுவதற்குப் பதிலாக ஒரு மாறியைக் குறிப்பிடலாம். மேலும், கோரிக்கைகளில் முக்கியமான தலைப்புகள் இருக்கும்போது, விரிவான வெளியீட்டில் கவனமாக இருங்கள். நீங்கள் ஒரு கட்டளையை யாருடனாவது பகிர வேண்டியிருந்தால், முதலில் அதைச் செம்மைப்படுத்துங்கள். யாராவது பெரிதாக்கினாலும் டோக்கன் படிக்கக்கூடிய வகையில், ஸ்கிரீன்ஷாட்டில் பாதி மங்கலாக்குவது போல் இல்லாமல், அதை முழுமையாகச் செம்மைப்படுத்துங்கள்.

5. HTTP நிலைக் குறியீடுகளைத் தவறாகப் புரிந்துகொள்ளுதல்

200 அல்லாத எல்லா பதில்களும் ஒரே மாதிரியான தோல்வியைக் குறிப்பதில்லை. 400 என்பது பொதுவாக கோரிக்கை தவறாக வடிவமைக்கப்பட்டுள்ளது அல்லது செல்லாதது என்பதைக் குறிக்கிறது. 401 என்பது அங்கீகாரச் சரிபார்ப்பைக் குறிக்கிறது. 403 என்பது சேவையகம் நீங்கள் யார் என்பதைப் புரிந்துகொண்டது, ஆனால் உங்களுக்கு அனுமதி இல்லை என்று கூறுகிறது என்பதாகும். 404 என்பது வழி தவறாக உள்ளது, அல்லது வள ஐடி (resource ID) இல்லை, அல்லது சில அமைப்புகளில், அது இருப்பதை நீங்கள் அறிய அனுமதிக்கப்படவில்லை என்பதைக் குறிக்கலாம். 429 என்பது விகித வரம்புச் சிக்கலைக் குறிக்கிறது. 500 என்பது சேவையகத் தரப்புத் தோல்வியைக் குறிக்கிறது, இருப்பினும் உங்கள் கோரிக்கையே அதற்கான தூண்டுதலாக இருக்கலாம்.

"API பழுதடைந்துள்ளது" என்று மட்டும் சொல்லாதீர்கள். சேவையானது நிலைக் குறியீடு, பதில் உள்ளடக்கம், தலைப்புகள் மற்றும் கோரிக்கை ஐடி (ஏதேனும் இருந்தால்) ஆகியவற்றைக் குறித்துக்கொள்ளுங்கள். நீங்கள் உதவி கேட்கும்போது, இது தேவையற்ற பல உரையாடல்களைத் தவிர்க்க உதவுகிறது.

6. API ஆனது POST-ஐ எதிர்பார்க்கும்போது GET-ஐப் பயன்படுத்துதல், அல்லது தரவைத் தவறான இடத்தில் அனுப்புதல்.

இது அடிப்படையானதாகத் தோன்றலாம், ஆனால் மக்கள் வெவ்வேறு எண்ட்பாயிண்ட்களுக்கு இடையில் மாறும்போது இது தொடர்ந்து நிகழ்கிறது. சில API-கள் வினவல் அளவுருக்களில் வடிப்பான்களை (filters) எடுத்துக்கொள்கின்றன. மற்றவை ஒரு JSON பாடியை எதிர்பார்க்கின்றன. வடிப்பான் ஆப்ஜெக்ட் ஒரு வினவல் சரத்திற்கு (query string) மிகவும் சிக்கலானதாக இருப்பதால், சில API-கள் தேடலுக்கு POST முறையைப் பயன்படுத்துகின்றன. சில எண்ட்பாயிண்ட்கள் PUT-க்கு பதிலாக PATCH முறையைக் கோருகின்றன. இதற்குப் பொதுவான ஒரு முறைமை என்று எதுவும் இல்லை, மேலும் பழக்கத்தின் காரணமாக ஏற்படும் திடீர் மாற்றங்கள் உங்களைச் சிக்கலில் மாட்டிவிடும்.

எண்ட்பாயிண்ட் ஆவணங்களை, குறிப்பாக அதன் மெத்தட் மற்றும் பாராமீட்டர்கள் எங்கு இடம்பெற வேண்டும் என்பதை, கவனமாகப் படியுங்கள். குவெரி ஸ்ட்ரிங், பாத் பாராமீட்டர், ஹெடர், ஃபார்ம் பாடி, ஜேசன் பாடி - மாலை 6:20 மணிக்கு ஒரு சோர்வான டெவலப்பருக்கு இவை அனைத்தும் "தரவு" போலத் தெரிவதால் மட்டும், அவற்றை ஒன்றுக்கொன்று மாற்றாகப் பயன்படுத்திவிட முடியாது.

7. பிரச்சினை கண்ணுக்குத் தெரியாதபோது வெர்போஸ் பயன்முறையைப் பயன்படுத்தாமல் இருப்பது

ஒரு கோரிக்கை தோல்வியடைந்து, பதில் பகுதி உங்களுக்கு எதையும் தெரிவிக்காதபோது, மேலும் விவரங்களைக் காட்ட cURL-இடம் கருவிகள் உள்ளன. -v கொடியானது இணைப்பு விவரங்கள், கோரிக்கை தலைப்புகள், பதில் தலைப்புகள், TLS பேச்சுவார்த்தை பிட்கள், வழிமாற்றங்கள் மற்றும் பிற பயனுள்ள தடயங்களை அச்சிடுகிறது. நீங்கள் தவறான ஹோஸ்ட்டை அணுகுகிறீர்கள், ஒரு தலைப்பைத் தவறவிடுகிறீர்கள், வழிமாற்றப்படுகிறீர்கள், அல்லது நீங்கள் நினைத்ததை விட வேறு எதையாவது அனுப்புகிறீர்கள் என்பதை அது வெளிப்படுத்தக்கூடும்.

ஆனால் அதை கவனமாகப் பயன்படுத்துங்கள். விரிவான பதிவுகளில் முக்கியமான தரவுகள் இருக்கலாம். அவை உள்ளூர் பிழைதிருத்தத்திற்கு மிகவும் சிறந்தவை, ஆனால் ஒரு பொதுவான சிக்கல் கண்காணிப்பானில் திருத்தாமல் அப்படியே ஒட்டுவதற்கு அவ்வளவு சிறந்தவை அல்ல.

8. வழிமாற்றங்களைப் புறக்கணித்தல்

சில எண்ட்பாயிண்ட்கள் HTTP-இலிருந்து HTTPS-க்கு, பழைய ஹோஸ்டிலிருந்து புதிய ஹோஸ்டுக்கு, அல்லது ஒரு சிறிய URL-இலிருந்து ஒரு கேனானிக்கல் ரூட்டிற்குத் திசைதிருப்புகின்றன. இயல்பாக, ஒரு பிரவுசரைப் போல cURL எப்போதும் திசைதிருப்புதல்களைப் பின்பற்றுவதில்லை. நீங்கள் 301, 302, 307, அல்லது 308 என்ற பதிலைக் கண்டால், கோரிக்கை இறுதி எண்ட்பாயிண்ட்டை அடைந்திருக்காது என்று பொருள்.

-L விருப்பம், வழிமாற்றங்களைப் பின்பற்றுமாறு cURL-க்கு அறிவுறுத்துகிறது. இருப்பினும், கவனம் செலுத்துங்கள். வழிமாற்றங்கள், குறிப்பாக மெத்தட்கள் மற்றும் கோரிக்கை பாடிகளுடன், செயல்பாட்டை மாற்றக்கூடும். நீங்கள் எங்கு சென்றடைந்தீர்கள் என்பதைப் புரிந்துகொள்ளாமல், சாதாரணமாக வழிமாற்றங்களைப் பின்பற்றினால், ஒரு லாகின் எண்ட்பாயிண்ட், அப்லோட் எண்ட்பாயிண்ட் அல்லது வெப்ஹூக் சோதனை விசித்திரமாக மாறக்கூடும்.

9. தவறான வடிவமைப்புடைய JSON-ஐ அனுப்புவதும், தவறான விஷயத்தை உற்றுப் பார்ப்பதும்

விடுபட்ட காற்புள்ளிகள், இறுதியில் வரும் காற்புள்ளிகள், சரங்களுக்குள் தப்பிக்கப்படாத மேற்கோள் குறிகள், கண்ணுக்குத் தெரியாத எழுத்துக்கள், கருத்துரைகளைக் கொண்ட நகலெடுக்கப்பட்ட தரவுப் பொதிகள். JSON கண்டிப்பானது, மேலும் உங்கள் ஷெல் கட்டளையை இயக்க அனுமதித்தால், cURL பிழையான JSON-ஐ மகிழ்ச்சியுடன் அனுப்பும். பின்னர் சேவையகம் அதை நிராகரிக்கிறது, பெரும்பாலும் நீங்கள் விரும்பும் அளவுக்குப் பயனுள்ளதாக இல்லாத ஒரு பிழைச் செய்தியுடன்.

எண்ட்பாயிண்ட்டைக் குறை கூறுவதற்கு முன், JSON பாடியைச் சரிபார்க்கவும். எல்லாவற்றையும் ஒரே பெரிய கட்டளையில் திணிப்பதற்குப் பதிலாக, பெரிய பேலோடுகளை ஒரு கோப்பில் வைத்து cURL மூலம் அனுப்பவும். இது படிப்பதற்கும் திருத்துவதற்கும் எளிதானது, மேலும் மேற்கோள் குறிகள் தப்பிச் செல்லும் ஒரு சிக்கலான வலைப்பின்னலாக மாறுவதற்கான வாய்ப்பும் குறைவு.

10. cURL உங்கள் முழுப் பயன்பாட்டையும் அல்ல, API-ஐ மட்டுமே சோதிக்கிறது என்பதை மறந்துவிடுவது.

ஒரு கோரிக்கை cURL-இல் செயல்பட்டு, உங்கள் செயலியில் தோல்வியடைந்தால், அது உங்கள் செயலி குறைபாடுள்ளது என்பதை நிரூபிக்காது; அப்படித் தோன்றினாலும் கூட. பொதுவாக, உங்கள் செயலி வேறு ஏதோ ஒன்றை அனுப்புகிறது என்பதே அதன் பொருள். வேறுபட்ட ஹெடர்கள். வேறுபட்ட பாடி. வேறுபட்ட குறியாக்கம். வேறுபட்ட அடிப்படை URL. வேறுபட்ட டோக்கன். வேறுபட்ட காலக்கெடு. வேறுபட்ட ப்ராக்ஸி. எப்போதுமே ஒரு வேறுபாடு இருக்கும்.

செயலியில் இருந்து அனுப்பப்படும் உண்மையான கோரிக்கையை cURL கோரிக்கையுடன் ஒப்பிடுங்கள். உலாவி மேம்பாட்டுக் கருவிகள், சேவையகப் பதிவுகள், API நுழைவாயில் பதிவுகள் மற்றும் HTTP கிளையன்ட் பிழைதிருத்தப் பதிவுகள் உதவக்கூடும். இதன் நோக்கம் "cURL-ஐ செயல்பட வைப்பது" அல்ல. உங்கள் செயலி அதே சரியான கோரிக்கையை நம்பகத்தன்மையுடன் அனுப்பும் அளவிற்கு, அந்தக் கோரிக்கையைத் துல்லியமாகப் புரிந்துகொள்வதே இதன் நோக்கமாகும்.

cURL-ஐ வலியற்றதாக மாற்றும் விரைவான பழக்கங்கள்

• சிறிய அளவில் தொடங்குங்கள். முதலில் அங்கீகாரத்தைச் சோதித்துப் பாருங்கள், பிறகு உள்ளடக்கத்தைச் சேர்க்கவும், அதன்பின் விருப்பத்திற்கேற்ப தலைப்புகள் அல்லது வடிப்பான்களைச் சேர்க்கவும்.
• உங்கள் சூழலுக்குப் பெயரிடுங்கள். நீங்கள் சோர்வாக இருக்கும்போது, சோதனை மற்றும் தயாரிப்பு URL-கள் எரிச்சலூட்டும் வகையில் ஒரே மாதிரியாகத் தோன்றக்கூடும்.
• எடுத்துக்காட்டுகளைத் தூய்மையாகப் பராமரிக்கவும். பகிர்வதற்கு முன் உண்மையான டோக்கன்கள், மின்னஞ்சல்கள், அடையாள எண்கள் மற்றும் வாடிக்கையாளர் தரவுகளை மாற்றவும்.
• சரியாகச் செயல்படும் என உறுதிசெய்யப்பட்ட கோரிக்கைகளைச் சேமித்து வையுங்கள். சோதிக்கப்பட்ட எடுத்துக்காட்டுகள் அடங்கிய ஒரு சிறிய கோப்புறை, ஒரு குழுவிற்கு வியக்கத்தக்க அளவு நேரத்தை மிச்சப்படுத்தும்.
• சேவையகம் உண்மையில் என்ன பெற்றது என்பதைச் சரிபார்க்கவும். பதிவுகள் கிடைத்தால், யூகித்துப் பார்ப்பதை விட அவை சிறந்தவை.

நீங்கள் ஒரு கோரிக்கையை உருவாக்கும்போது, அடிப்படை வடிவமைப்புப் பிழைகளைத் தவிர்க்க விரும்பினால், cURL கட்டளை உருவாக்கி (command Generator) ஒரு பயனுள்ள தொடக்கப் புள்ளியாக இருக்கும், குறிப்பாகத் தலைப்புகள் (headers) மற்றும் தரவுப் பொதியின் (payload) அமைப்புக்கு. இருப்பினும், முடிவைச் சரிபார்க்கவும், ஏனெனில் உண்மையான பிழைதிருத்தம் என்பது எப்போதும் நுணுக்கங்களில்தான் அடங்கியுள்ளது.

cURL மிகச் சிறந்த முறையில் எளிமையானது, ஆனால் அது ஒரு மாயாஜாலம் அல்ல. மிகவும் எரிச்சலூட்டும் API சிக்கல்கள் என்பவை, வெளிப்படையாகத் தெரியும் சிறிய பொருத்தமின்மைகளே ஆகும். ஒரு மேற்கோள் குறி தவறாக உள்ளது. ஒரு ஹெடர் விடுபட்டுள்ளது. ஒரு டோக்கன் காலாவதியாகிவிட்டது. கோரிக்கை பாடி உங்கள் மனதில் சரியாகத் தோன்றலாம், ஆனால் அது நெட்வொர்க்கில் தவறாக இருக்கலாம். இரண்டு நிமிடங்கள் நிதானித்து, முதலில் சலிப்பூட்டும் விஷயங்களைச் சரிபார்க்கவும். அப்போது, பல சமயங்களில் அந்த "மர்மமான API சிக்கல்" என்பது, ஒரு போலி மீசையுடன் கூடிய ஒரு சாதாரண தட்டச்சுப் பிழையாகவே மாறிவிடும்.