REST இன் கண்ணோட்டம். பகுதி 2: கிளையன்ட் மற்றும் சர்வர் இடையேயான தொடர்பு

REST இன் கண்ணோட்டம். பகுதி 1: ஓய்வு என்றால் என்ன? இந்த பகுதியில், கிளையன்ட் மற்றும் சர்வர் இடையே தொடர்பு எவ்வாறு நடைபெறுகிறது என்பதை ஆழமாகப் பார்ப்போம். வழியில், புதிய விதிமுறைகளைக் கண்டுபிடித்து அவற்றை விளக்குவோம். எல்லாம் தெளிவாக இருப்பதை உறுதிசெய்ய, எடுத்துக்காட்டாக, RESTful பயன்பாட்டைப் பயன்படுத்தி கிளையன்ட்-சர்வர் தொடர்பை நாங்கள் பகுப்பாய்வு செய்வோம். வாடிக்கையாளர்கள் மற்றும் அவர்களின் ஆர்டர்களைப் பற்றிய தகவல்களைச் சேமிக்கும் ஒரு வலை பயன்பாட்டை நாங்கள் உருவாக்குகிறோம் என்று வைத்துக்கொள்வோம். வேறு வார்த்தைகளில் கூறுவதானால், எங்கள் கணினி சில நிறுவனங்களில் செயல்பாடுகளைச் செய்ய முடியும்: அவற்றை உருவாக்குதல், திருத்துதல் மற்றும் நீக்குதல் மற்றும் அவற்றைப் பற்றிய தகவலைக் காண்பிக்கும். இந்த நிறுவனங்கள் இருக்கும்:

• வாடிக்கையாளர்கள் (வாடிக்கையாளர்கள்)
• ஆர்டர்கள் (வாடிக்கையாளர் ஆர்டர்கள்)
• பொருட்கள் (தயாரிப்புகள்)

ஒரு RESTful கட்டமைப்பில், வாடிக்கையாளர்கள் தரவை மீட்டெடுக்க அல்லது மாற்ற ஒரு சேவையகத்திற்கு கோரிக்கைகளை அனுப்புகிறார்கள், பின்னர் சேவையகங்கள் வாடிக்கையாளர்களின் கோரிக்கைகளுக்கு பதில்களை அனுப்புகின்றன.

கோரிக்கைகளை

வாடிக்கையாளர் கோரிக்கைகள் எப்போதும் HTTP நெறிமுறையைப் பயன்படுத்தி செய்யப்படுகின்றன. பொதுவாக, HTTP கோரிக்கைகள் பல கூறுகளைக் கொண்டிருக்கும்:

• HTTP முறை
• தலைப்பு
• URI
• கோரிக்கை உடல்

கீழே ஒவ்வொரு கூறுகளையும் இன்னும் விரிவாகக் கருதுவோம்.

URIகள் மற்றும் ஆதாரங்கள்

கோரிக்கைகள் மூலம் வாடிக்கையாளர் பெறும் அல்லது மாற்றியமைக்கும் தரவு ஆதாரங்கள் எனப்படும். கிளையண்ட்-சர்வர் தொடர்பு என்பது ஆதாரங்களைக் கையாள்வதாகும். REST இல், ஆதாரங்கள் நீங்கள் ஒரு பெயரைக் கொடுக்கலாம். ஒரு வகையில், அவை ஜாவாவில் உள்ள வகுப்புகள் போன்றவை. ஜாவாவில், எதற்கும் ஒரு வகுப்பை உருவாக்கலாம். எனவே REST இல், ஒரு ஆதாரம் எதுவாகவும் இருக்கலாம்: ஒரு பயனர், ஒரு ஆவணம், ஒரு அறிக்கை, ஒரு ஆர்டர். இது ஏதேனும் ஒரு பொருளின் சுருக்கமாக இருக்கலாம் அல்லது குறிப்பிட்ட ஏதாவது ஒரு படம், வீடியோ, அனிமேஷன் அல்லது PDF கோப்பாக இருக்கலாம். எங்கள் எடுத்துக்காட்டில், எங்களிடம் 3 ஆதாரங்கள் உள்ளன:

• வாடிக்கையாளர்கள் (வாடிக்கையாளர்கள்)
• ஆர்டர்கள் (வாடிக்கையாளர் ஆர்டர்கள்)
• பொருட்கள் (தயாரிப்புகள்)

வாடிக்கையாளர்கள் எண்ட் பாயிண்ட்ஸ் எனப்படும் ஆதார இடங்களுக்கு கோரிக்கைகளை அனுப்புகிறார்கள். எளிமையாகச் சொன்னால், ஒரு இறுதிப்புள்ளி என்பது நெட்வொர்க்கில் உள்ள முகவரி போன்றது. ஆழமாக மூழ்கினால், ஒரு இறுதிப்புள்ளி URI என்று சொல்லலாம், அதாவது ஒரு சுருக்கம் அல்லது இயற்பியல் வளத்தை அடையாளம் காட்டும் எழுத்துகளின் வரிசை. சீரான ஆதார அடையாளங்காட்டி (URI) சில நேரங்களில் ஒரு இறுதிப்புள்ளி அல்லது URI, ஒரு பாதை என்று அழைக்கப்படுகிறது, அதாவது வளத்திற்கான பாதை. இந்தக் கட்டுரையின் நோக்கங்களுக்காக, URI என்ற சொல்லைப் பயன்படுத்துவோம். ஒவ்வொரு குறிப்பிட்ட வளத்திற்கும் ஒரு தனிப்பட்ட URI இருக்க வேண்டும். ஒவ்வொரு வளத்திற்கும் எப்போதும் அதன் சொந்த URI இருப்பதை உறுதிசெய்வதற்கு சர்வர் டெவலப்பர் பொறுப்பு. எங்கள் எடுத்துக்காட்டில், நாங்கள் டெவலப்பர்கள், எனவே எங்களுக்குத் தெரிந்த வழியில் அதைச் செய்வோம். ஒரு தொடர்புடைய தரவுத்தளத்தில் முதன்மை விசைகளாக எண் அடையாளங்காட்டிகளை ஒதுக்குவது வழக்கமாக இருப்பதைப் போலவே, ஒவ்வொரு வளத்திற்கும் REST இல் அதன் சொந்த ஐடி உள்ளது. REST இல் உள்ள ஆதார ஐடி, வளத்தைப் பற்றிய தகவல்களைச் சேமிக்கும் தரவுத்தளத்தில் உள்ள பதிவின் ஐடியுடன் பெரும்பாலும் பொருந்துகிறது. REST URIகள் வழக்கமாக சில வளங்களை விவரிக்கும் பெயர்ச்சொல்லின் பன்மை வடிவத்துடன் தொடங்குகின்றன. உதாரணத்திற்கு, "

• / வாடிக்கையாளர்கள் — கிடைக்கக்கூடிய அனைத்து வாடிக்கையாளர்களின் URI
• /வாடிக்கையாளர்கள்/23 — குறிப்பிட்ட வாடிக்கையாளரின் URI, அதாவது ID=23 உள்ள வாடிக்கையாளர்
• /வாடிக்கையாளர்கள்/4 — குறிப்பிட்ட வாடிக்கையாளரின் URI, அதாவது ஐடி=4 கொண்ட வாடிக்கையாளர்.

ஆனால் அதெல்லாம் இல்லை. ஆர்டர்களைச் சேர்ப்பதன் மூலம் URIஐ நீட்டிக்கலாம்:

• /வாடிக்கையாளர்கள்/4/ஆர்டர்கள் — வாடிக்கையாளர் எண். 4 ஆல் செய்யப்பட்ட அனைத்து ஆர்டர்களின் URI
• /வாடிக்கையாளர்கள்/1/ஆர்டர்கள்/12 — வாடிக்கையாளர் எண். 1 ஆல் செய்யப்பட்ட ஆர்டர் எண். 12 இன் URI.

கூடுதல் தயாரிப்புகளைச் சேர்ப்பதன் மூலம் விரிவாக்கத்தைத் தொடர்ந்தால், நாங்கள் பெறுகிறோம்:

• /வாடிக்கையாளர்கள்/1/orders/12/items — வாடிக்கையாளர் எண். 1 ஆல் செய்யப்பட்ட வரிசை எண். 12ல் உள்ள அனைத்து தயாரிப்புகளின் பட்டியலின் URI.

நாம் கூடு கட்டும் நிலைகளைச் சேர்க்கும்போது, ​​URIகளை உள்ளுணர்வுடன் உருவாக்குவதே முக்கியமான விஷயம்.

HTTP முறை

HTTP முறை என்பது எந்த எழுத்துகளின் வரிசையாகும் (கட்டுப்பாட்டு எழுத்துகள் மற்றும் பிரிப்பான்கள் தவிர), இது வளத்தில் செய்யப்படும் முக்கிய செயல்பாட்டைக் குறிக்கிறது. பல பொதுவான HTTP முறைகள் உள்ளன. RESTful சேவைகளில் அடிக்கடி பயன்படுத்தப்படுபவற்றை நாங்கள் பட்டியலிடுவோம்:

• பெறவும் - ஒரு குறிப்பிட்ட ஆதாரம் (அதன் ஐடி மூலம்) அல்லது வளங்களின் சேகரிப்பு பற்றிய தகவலைப் பெறவும்
• POST - ஒரு புதிய ஆதாரத்தை உருவாக்கவும்
• PUT - ஒரு ஆதாரத்தை மாற்றவும் (அதன் ஐடி மூலம்)
• நீக்கு - ஒரு ஆதாரத்தை நீக்கவும் (அதன் ஐடி மூலம்)

தலைப்புகள்

கோரிக்கைகள் மற்றும் பதில்களில் HTTP தலைப்புகள் உள்ளன. கோரிக்கை (அல்லது பதில்) பற்றிய கூடுதல் தகவலை அவை தெரிவிக்கின்றன. தலைப்புகள் முக்கிய மதிப்பு ஜோடிகள். விக்கிபீடியாவில் மிகவும் பொதுவான தலைப்புகளின் பட்டியலை நீங்கள் பார்க்கலாம் . REST ஐப் பொறுத்தவரை, வாடிக்கையாளர்கள் பெரும்பாலும் சேவையகத்திற்கான கோரிக்கைகளில் "ஏற்றுக்கொள்" என்ற தலைப்பை அனுப்புவார்கள். கிளையன்ட் எந்த வடிவத்தில் பதிலைப் பெற எதிர்பார்க்கிறார் என்பதை சேவையகத்திற்குச் சொல்ல இந்த தலைப்பு தேவை. MIME வகைகளின் பட்டியலில் பல்வேறு வடிவங்கள் கொடுக்கப்பட்டுள்ளன. MIME (மல்டிபர்ப்பஸ் இன்டர்நெட் மெயில் நீட்டிப்புகள்) என்பது தகவல்களை குறியாக்கம் செய்வதற்கும் செய்திகளை வடிவமைப்பதற்கும் ஒரு விவரக்குறிப்பாகும், எனவே அவை இணையத்தில் அனுப்பப்படும். ஒவ்வொரு MIME வகையும் ஒரு சாய்வால் பிரிக்கப்பட்ட இரண்டு பகுதிகளைக் கொண்டுள்ளது - ஒரு வகை மற்றும் துணை வகை. பல்வேறு வகையான கோப்புகளுக்கான MIME வகைகளின் எடுத்துக்காட்டுகள்:

• text — text/plain, text/css, text/html
• படம் - படம்/பிஎன்ஜி, படம்/ஜேபிஇஜி, படம்/ஜிஃப்
• ஆடியோ - ஆடியோ/வேவ், ஆடியோ/எம்பிஜி
• video — video/mp4, video/ogg
• பயன்பாடு - பயன்பாடு/json, பயன்பாடு/pdf, பயன்பாடு/xml, பயன்பாடு/ஆக்டெட்-ஸ்ட்ரீம்

எடுத்துக்காட்டாக, கோரிக்கையில் இது போன்ற தலைப்பு இருக்கலாம்:

Accept:application/json

கிளையன்ட் JSON வடிவத்தில் பதிலைப் பெற எதிர்பார்க்கிறார் என்று இந்த தலைப்பு சேவையகத்திற்குச் சொல்கிறது.

கோரிக்கை உடல்

இது வாடிக்கையாளர் சேவையகத்திற்கு அனுப்பிய செய்தியாகும். கோரிக்கைக்கு உடல் உள்ளதா இல்லையா என்பது HTTP கோரிக்கையின் வகையைப் பொறுத்தது. எடுத்துக்காட்டாக, GET மற்றும் DELETE கோரிக்கைகளில் பொதுவாக எந்த கோரிக்கை அமைப்பும் இருக்காது. ஆனால் PUT மற்றும் POST கோரிக்கைகள் முடியும் - இது கோரிக்கையின் நோக்கத்தைப் பொறுத்தது. எல்லாவற்றிற்கும் மேலாக, ஐடியைப் பயன்படுத்தி தரவைப் பெற மற்றும்/அல்லது நீக்க (இது URL இல் அனுப்பப்பட்டது), நீங்கள் சேவையகத்திற்கு கூடுதல் தரவை அனுப்ப வேண்டியதில்லை. ஆனால் ஒரு புதிய ஆதாரத்தை (POST கோரிக்கை மூலம்) உருவாக்க, நீங்கள் ஆதாரத்தை அனுப்ப வேண்டும். ஏற்கனவே உள்ள வளத்தை மாற்றுவதற்கும் இதுவே உண்மை. REST இல், கோரிக்கை அமைப்பு பெரும்பாலும் XML அல்லது JSON வடிவத்தில் அனுப்பப்படும். JSON வடிவம் மிகவும் பொதுவானது. ஒரு புதிய ஆதாரத்தை உருவாக்க சேவையகத்திற்கு ஒரு கோரிக்கையை அனுப்ப விரும்புகிறோம் என்று வைத்துக்கொள்வோம். நீங்கள் மறக்கவில்லை என்றால், வாடிக்கையாளர் ஆர்டர்களை நிர்வகிக்கும் பயன்பாட்டின் உதாரணத்தை நாங்கள் கருத்தில் கொண்டோம். புதிய வாடிக்கையாளரை உருவாக்க விரும்புகிறோம் என்று வைத்துக்கொள்வோம். எங்கள் விஷயத்தில், பின்வரும் வாடிக்கையாளர் தகவலை நாங்கள் சேமிக்கிறோம்: பெயர், மின்னஞ்சல், தொலைபேசி எண். கோரிக்கையின் உள்ளடக்கம் பின்வரும் JSON ஆக இருக்கலாம்:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

கோரிக்கைகளை ஒன்றாக இணைத்தல்

எனவே, வாடிக்கையாளர் கோரிக்கையில் என்ன இருக்கக்கூடும் என்பதை நாங்கள் ஆய்வு செய்துள்ளோம். விளக்கங்களுடன் கோரிக்கைகளின் சில உதாரணங்களை இப்போது தருவோம்

பதில்கள்

சேவையக பதில்களைப் பற்றி சில வார்த்தைகளைச் சொல்லலாம். ஒரு பதில் பொதுவாக பின்வரும் பகுதிகளைக் கொண்டுள்ளது:

• பதில் குறியீடு
• தலைப்புகள்
• பதில் உடல்

பொதுவாக, பதில் தலைப்புகள் கோரிக்கை தலைப்புகளிலிருந்து மிகவும் வேறுபட்டவை அல்ல. கூடுதலாக, சில தலைப்புகள் பதில்கள் மற்றும் கோரிக்கைகள் இரண்டிலும் பயன்படுத்தப்படுகின்றன. கோரிக்கை அமைப்பு தொடர்பாக எல்லாம் தெளிவாக உள்ளது என்று நினைக்கிறேன். வாடிக்கையாளரால் கோரப்பட்ட தகவலை உடல் அடிக்கடி வழங்குகிறது. GET கோரிக்கைகளுக்குப் பதில் அளிக்கப்படும் தகவல் JSON வடிவத்திலும் இருக்கலாம். ஆனால் கடைசிப் பகுதி இன்னும் கொஞ்சம் சுவாரஸ்யம்.

HTTP மறுமொழி குறியீடுகள்

HTTP மறுமொழி குறியீடுகளை இன்னும் விரிவாகக் கருதுவோம். HTTP நிலைக் குறியீடு என்பது HTTP நெறிமுறை மூலம் செய்யப்படும் கோரிக்கைகளுக்கான சர்வர் பதிலின் முதல் வரியின் ஒரு பகுதியாகும். இது மூன்று தசம இலக்கங்களைக் கொண்ட ஒரு முழு எண். முதல் இலக்கமானது பதில் நிலைக் குறியீட்டின் வகுப்பைக் குறிக்கிறது. பதில் குறியீடு பொதுவாக ஆங்கிலத்தில் ஒரு விளக்கச் சொற்றொடரைத் தொடர்ந்து ஒரு இடைவெளியால் பிரிக்கப்படும். இந்தச் சொற்றொடரை மனிதர்கள் படிக்கக் கூடிய பதிலுக்குக் காரணம். எடுத்துக்காட்டுகள்:

• 201 உருவாக்கப்பட்டது
• 401 அங்கீகரிக்கப்படாதது
• 507 போதிய சேமிப்பு இல்லை

மறுமொழி குறியீடு கிளையண்டிற்கு கோரிக்கையின் முடிவைக் கூறுகிறது மற்றும் அடுத்து என்ன நடவடிக்கை எடுக்க வேண்டும் என்பதை தீர்மானிக்க அனுமதிக்கிறது. பதில் குறியீடுகள் பல வகுப்புகள் அல்லது குழுக்களாக பிரிக்கப்பட்டுள்ளன:

• 1XX - தகவல்
• 2XX — இந்த குறியீடுகள் வாடிக்கையாளரின் கோரிக்கை வெற்றிகரமாகப் பெறப்பட்டு செயலாக்கப்பட்டது என்பதைக் குறிக்கிறது
• 3XX — இந்த குறியீடுகள் கிளையண்டிற்கு, செயல்பாட்டை வெற்றிகரமாக முடிப்பதற்கு, வழக்கமாக வேறு URIக்கு கூடுதல் கோரிக்கை செய்யப்பட வேண்டும் என்று தெரிவிக்கின்றன.
• 4XX - கிளையண்ட் பிழை. இத்தகைய குறியீடுகள் தவறாக உருவாக்கப்பட்ட கோரிக்கையின் விளைவாக இருக்கலாம். மற்றொரு உதாரணம், நன்கு அறியப்பட்ட "404 கிடைக்கவில்லை" குறியீடு ஆகும், இது ஒரு கிளையன்ட் இல்லாத ஆதாரத்தை கோரும் போது ஏற்படும்.
• 5XX - சர்வர் பிழை. செயல்பாட்டின் தோல்விக்கு சேவையகம் பொறுப்பானால், இந்த குறியீடுகள் கிளையண்டிற்குத் திரும்பும்

REST இன் கண்ணோட்டம். பகுதி 3: ஸ்பிரிங் பூட்டில் ஒரு RESTful சேவையை உருவாக்குதல்