8.1 ரிமோட் ஏபிஐ அணுகுமுறை
கிளையன்ட்-சர்வர் கட்டமைப்பை உருவாக்கும் போது அனைத்து புரோகிராமர்களும் ஒரே தவறை செய்கிறார்கள். அவை சேவையகத்திற்கான கோரிக்கைகளை முறை அழைப்புகளாகக் கருதத் தொடங்குகின்றன .
நீங்கள் சேவையகத்தில் அறிக்கை உருவாக்கும் செயல்முறையைத் தொடங்க விரும்புகிறீர்கள், இது போன்ற கோரிக்கையை ஏன் அனுப்பக்கூடாது:
http://server.com/startDocumentGeneration?paramsஅறிக்கை முடிந்த பிறகு அதை எவ்வாறு பதிவிறக்குவது? இதைச் செய்ய, நாங்கள் மற்றொரு முறையை எழுதுவோம்:
http://server.com/getDocumentசர்வர் HttpSessionநமது ஆவணத்தில் தகவல்களைச் சேமிக்கிறது, மேலும் ஆவணம் உருவாக்கப்பட்டவுடன், சர்வர் அதைத் திருப்பித் தரும்.
அருமையான அணுகுமுறை. அல்லது இல்லை?
அணுகுமுறை உண்மையில் பயங்கரமானது. விஷயம் என்னவென்றால், சர்வர் ஆவண எண்ணை நினைவில் வைத்திருக்க வேண்டும். வேறு வார்த்தைகளில் கூறுவதானால், புதிய முறை அழைப்புகளைச் சரியாகச் செயல்படுத்த, சேவையகம் முந்தைய முறைகளை அழைப்பதன் முடிவுகளை நினைவில் வைத்திருக்க வேண்டும்.
இணையத்தில், இது ஒரு பெரிய பிரச்சனை. இணையம் மறைந்து போகலாம், உலாவி மூடலாம். பக்கத்தை மீண்டும் ஏற்றலாம் அல்லது தற்செயலாக இணைப்பைக் கிளிக் செய்யலாம் மற்றும் பல. சேவையகம் முந்தைய பயனர் கோரிக்கைகளிலிருந்து மெகாபைட் தரவை தொடர்ந்து சேமிக்கும் ...
சேவையகத்துடன் வசதியான வேலைக்காக, சேவையகத்திற்கான முந்தைய கோரிக்கைகளின் தரவு உங்களிடம் எப்போதும் இருக்கும் என்று நீங்கள் எதிர்பார்க்க முடியாது.
சேவையகத்தின் முறைகளை எவ்வாறு அழைப்பது? சரியான பதில் பயங்கரமாக இருக்கும்: வழி இல்லை!
8.2 ஓய்வு அணுகுமுறை
புரோகிராமர்கள் அடிப்படைகளுக்குச் சென்று, ஆரம்பத்தில் கோரிக்கையில் சேவையகத்தில் உள்ள கோப்பிற்கான பாதை இருப்பதை நினைவில் வைத்தனர்:
http://server.com/path?paramsஇந்த அணுகுமுறையை அதிகபட்சமாக பயன்படுத்த முடிவு செய்தோம்.
இப்போது சர்வர் ஒரு மரத்தின் வடிவத்தில் வெளியே தெரியும் தரவுகளின் களஞ்சியமாக கருதப்படுகிறது .
அனைத்து பயனர்களின் பட்டியலைப் பெற விரும்பினால், வினவலை அழைக்கவும்:
http://server.com/usersபயனர் 113 இல் தரவைப் பெற விரும்பினால், வினவலை இயக்கவும்:
http://server.com/users/113மேலும், அனைத்தும் ஒரே மாதிரியாக.
மீண்டும், சர்வர் ஒரு மர வடிவில் வெளியே தெரியும் தரவு களஞ்சியமாக பார்க்கப்படுகிறது.
தரவைப் பெறலாம் - கோரிக்கைகளைப் பெறலாம் , மாற்றியமைக்கலாம் - இடுகை கோரிக்கை மற்றும் நீக்கப்பட்டது - DELETE கோரிக்கை .
8.3 மாநிலம் இல்லை
கிளையன்ட் மற்றும் சர்வர் இடையேயான தொடர்புக்கான REST நெறிமுறைக்கு பின்வரும் நிபந்தனை தேவைப்படுகிறது: கிளையண்டின் கோரிக்கைகளுக்கு இடையில், கிளையண்டின் நிலை குறித்த எந்த தகவலும் சேவையகத்தில் சேமிக்கப்படவில்லை.
கிளையண்டின் அனைத்து கோரிக்கைகளும் ஒவ்வொரு முறையும் கோரிக்கையை நிறைவேற்ற தேவையான அனைத்து தகவல்களையும் சேவையகம் பெறும் வகையில் வடிவமைக்கப்பட வேண்டும் . அமர்வு நிலை கிளையன்ட் பக்கத்தில் சேமிக்கப்படுகிறது.
கிளையன்ட் கோரிக்கைகளின் செயலாக்கத்தின் போது, வாடிக்கையாளர் ஒரு இடைநிலை நிலையில் இருப்பதாகக் கருதப்படுகிறார். ஒவ்வொரு தனிப்பட்ட பயன்பாட்டு நிலையும் அடுத்த முறை கிளையன்ட் தாக்கும் போது பயன்படுத்தக்கூடிய இணைப்புகளால் குறிப்பிடப்படுகிறது.
8.4 இடைமுகம் சீரான தன்மை
சேவையகத்திலிருந்து பொருட்களை மீட்டெடுக்கப் பயன்படுத்தப்படும் அனைத்து பாதைகளும் தரப்படுத்தப்பட்டுள்ளன. இது மிகவும் வசதியானது, குறிப்பாக நீங்கள் மற்ற REST சேவையகங்களிலிருந்து தரவைப் பெறுகிறீர்கள் என்றால்.
அனைத்து பொருள் இடைமுகங்களும் மூன்று நிபந்தனைகளுக்கு இணங்க வேண்டும்:
வள அடையாளம்
அனைத்து ஆதாரங்களும் URI ஐப் பயன்படுத்தி கோரிக்கைகளில் அடையாளம் காணப்படுகின்றன. சேவையகத்தின் உள்ளே உள்ள ஆதாரங்கள் வாடிக்கையாளர்களுக்குத் திருப்பியளிக்கப்படும் பார்வைகளிலிருந்து தனித்தனியாக இருக்கும். எடுத்துக்காட்டாக, ஒரு சேவையகம் ஒரு தரவுத்தளத்திலிருந்து HTML, XML அல்லது JSON என தரவை அனுப்பலாம், இவை இரண்டும் சேவையகத்திற்குள் இருக்கும் சேமிப்பக வகை அல்ல.
ஒரு பார்வை மூலம் வளங்களை கையாளுதல்
கிளையன்ட் மெட்டாடேட்டா உட்பட வளத்தின் பிரதிநிதித்துவத்தை சேமித்து வைத்தால், சர்வரில் உள்ள வளத்தை மாற்ற அல்லது நீக்க போதுமான தகவல் உள்ளது.
"சுய விவரிப்பு" செய்திகள்
ஒவ்வொரு செய்தியிலும் அதை எவ்வாறு கையாள்வது என்பதைப் புரிந்துகொள்ள போதுமான தகவல்கள் உள்ளன. எடுத்துக்காட்டாக, பயனரைப் பற்றிய தகவல் உங்களுக்குத் தேவைப்பட்டால், சேவையகம் உங்களுக்கு ஒரு JSON பொருளைத் தரும், அங்கு பெயர், முகவரி புலங்கள் இருக்கும்.
பதிலில் முதல் எண் வயது, இரண்டாவது பிறந்த தேதி என்பதை வாடிக்கையாளர் தெரிந்து கொள்ள வேண்டிய சூழ்நிலை இருக்கக்கூடாது.
8.5 கேச்சிங்
REST அணுகுமுறையானது தரவுக் கோரிக்கைகள் HTTP நெறிமுறை வழியாகச் செய்யப்படுவதாகக் கருதுகிறது. எனவே, GET கோரிக்கையை அழைப்பதன் மூலம் பொருள்கள் பெறப்படுகின்றன. GET கோரிக்கையின் மூலம் பெறப்பட்ட அனைத்து ஆதாரங்களையும் போலவே, HTTP ஆதாரங்களைத் தேக்ககப்படுத்துவதற்கான அனைத்து விதிகளுக்கும் உட்பட்டவை என்பதே இதன் பொருள்.
அதாவது, REST API மூலம் பெறப்பட்ட தரவு, இணைய சேவையகங்களில் உள்ள நிலையான ஆதாரங்களைப் போலவே தற்காலிகமாக சேமிக்கப்படுகிறது. அழகு :)