REST இன் கண்ணோட்டம். பகுதி 1: ஓய்வு என்றால் என்ன?

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

1. முதல் பகுதியில், REST இன் வரலாற்றை உள்ளடக்கி, REST அடிப்படையிலான கொள்கைகளை விவரிப்போம்.

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

3. மூன்றாவதாக, ஒரு சிறிய RESTful பயன்பாட்டை எழுதுவோம், அதை "Postman" என்ற நிரலைப் பயன்படுத்தி சோதனை செய்வோம்.

கட்டுரை பின்வரும் விதிமுறைகளை நன்கு அறிந்த வாசகர்களுக்காக வடிவமைக்கப்பட்டுள்ளது:

• HTTP
• URL மற்றும் URI
• JSON மற்றும் (சிறிதளவு) எக்ஸ்எம்எல்
• சார்பு ஊசி

பகுதி 1. REST என்றால் என்ன?

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

REST இன் வரலாறு

REST என்ற சொல் HTTP நெறிமுறையை உருவாக்கியவர்களில் ஒருவரான ராய் ஃபீல்டிங்கால் அவரது Ph.D இல் அறிமுகப்படுத்தப்பட்டது. 2000 ஆம் ஆண்டில் "கட்டடக்கலை பாணிகள் மற்றும் நெட்வொர்க் அடிப்படையிலான மென்பொருள் கட்டமைப்புகளின் வடிவமைப்பு" என்ற தலைப்பில் ஆய்வறிக்கை. REST என்ற சொல்லை இன்னும் இளமையாக அழைக்க முடியும் என்றாலும், உலகளாவிய வலையின் மையத்தில் அது பிரதிபலிக்கிறது. இந்த வார்த்தையின் வரலாற்றில் நாம் ஆழமாக மூழ்க மாட்டோம். நீங்கள் முதன்மை ஆதாரங்களுக்குள் நுழைய விரும்பினால், ஃபீல்டிங்கின் ஆய்வுக் கட்டுரையைப் பார்க்கவும் .

REST கட்டுப்பாடுகள் மற்றும் கொள்கைகள்

மேலே குறிப்பிட்டுள்ளபடி, விநியோகிக்கப்பட்ட அமைப்பின் கூறுகள் எவ்வாறு ஒன்றுடன் ஒன்று தொடர்பு கொள்ள வேண்டும் என்பதை REST வரையறுக்கிறது. பொதுவாக, இது ஒரு கோரிக்கை-பதில் செயல்முறை மூலம் நடக்கும். கோரிக்கையை அனுப்பும் கூறு கிளையன்ட் என்றும் , கோரிக்கையைச் செயல்படுத்தி கிளையண்டிற்கு பதிலை அனுப்பும் கூறு சர்வர் என்றும் அழைக்கப்படுகிறது .. கோரிக்கைகள் மற்றும் பதில்கள் பெரும்பாலும் HTTP நெறிமுறை வழியாக அனுப்பப்படுகின்றன. HTTP என்பது HyperText Transfer Protocol என்பதன் சுருக்கம். பொதுவாக, சர்வர் என்பது சில இணையப் பயன்பாடு. வாடிக்கையாளர் ஏறக்குறைய எதுவாகவும் இருக்கலாம். எடுத்துக்காட்டாக, சேவையகத்திலிருந்து தரவைக் கோரும் மொபைல் பயன்பாடு. அல்லது தரவைப் பதிவிறக்க, இணையப் பக்கத்திலிருந்து சேவையகத்திற்கு கோரிக்கைகளை அனுப்பும் உலாவி. விண்ணப்பம் A ஆனது விண்ணப்பம் B இலிருந்து தரவைக் கோரலாம். இந்த நிலையில், A என்பது B ஐப் பொறுத்து ஒரு கிளையன்ட், மற்றும் B என்பது A ஐப் பொறுத்து ஒரு சேவையகமாகும். அதே நேரத்தில், A B, C, D, போன்றவற்றின் கோரிக்கைகளை செயலாக்க முடியும். இந்த வழக்கில், பயன்பாடு A என்பது சேவையகம் மற்றும் கிளையன்ட் ஆகிய இரண்டும் ஆகும். எல்லாம் சூழலைப் பொறுத்தது. ஒன்று நிச்சயம்: கோரிக்கையை அனுப்பும் கூறு வாடிக்கையாளர். கோரிக்கையைப் பெறும், செயலாக்கும் மற்றும் பதிலளிக்கும் கூறு சேவையகம். எனினும், கோரிக்கை-பதில் செயல்முறை மூலம் கூறுகள் தொடர்பு கொள்ளும் ஒவ்வொரு அமைப்பும் ஒரு RESTful அமைப்பு அல்ல. ஒரு அமைப்பு RESTful எனக் கருதப்பட, அது ஆறு REST கட்டுப்பாடுகளுக்கு இணங்க வேண்டும்:

1. கிளையண்ட்-சர்வர் கட்டமைப்பு

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

2. நாடற்றவர்

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

3. Cacheable

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

4. சீரான இடைமுகம்

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

5. அடுக்குகள்

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

6. தேவைக்கான குறியீடு (விரும்பினால்)

ஆப்லெட்டுகள் அல்லது ஸ்கிரிப்ட்கள் வடிவில் சேவையகத்திலிருந்து குறியீட்டைப் பதிவிறக்குவதன் மூலம் கிளையன்ட் அதன் செயல்பாட்டை விரிவாக்க முடியும் என்பதை இந்தக் கட்டுப்பாடு குறிக்கிறது.

ஒரு RESTful கட்டிடக்கலையின் நன்மைகள்

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

• செயல்திறன் (ஒரு தற்காலிக சேமிப்பின் பயன்பாடு காரணமாக)
• அளவீடல்
• வெளிப்படையான தொடர்பு
• எளிய இடைமுகங்கள்
• பெயர்வுத்திறன்
• எளிதாக மாற்றங்களைச் செய்யும் திறன்
• வளர்ச்சி மற்றும் புதிய தேவைகளுக்கு ஏற்ப திறன்

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