హాయ్! ఈ రోజు మనం చాలా ఆసక్తికరమైన మరియు, ముఖ్యంగా, లేబర్ మార్కెట్లో అధిక డిమాండ్ ఉన్న అంశం గురించి నేర్చుకుంటాము: REST. మేము REST యొక్క మా అవలోకనాన్ని మూడు భాగాలుగా విభజిస్తాము:
మొదటి భాగంలో, మేము REST చరిత్రను కవర్ చేస్తాము మరియు REST ఆధారంగా ఉన్న సూత్రాలను వివరిస్తాము.
రెండవది, HTTP ప్రోటోకాల్ ద్వారా క్లయింట్ మరియు సర్వర్ మధ్య కమ్యూనికేషన్ ఎలా జరుగుతుందో మేము పరిశీలిస్తాము.
మూడవదానిలో, మేము "పోస్ట్‌మాన్" అనే ప్రోగ్రామ్‌ని ఉపయోగించి పరీక్షించే చిన్న RESTful అప్లికేషన్‌ను వ్రాస్తాము.
వ్యాసం క్రింది నిబంధనలతో తెలిసిన పాఠకుల కోసం ఉద్దేశించబడింది:
HTTP
URL మరియు URI
JSON మరియు (తక్కువ మేరకు) XML
డిపెండెన్సీ ఇంజెక్షన్
పార్ట్ 1. REST అంటే ఏమిటి?
IT ప్రపంచంలో చాలా వరకు REST అనేది ఒక సంక్షిప్త రూపం. ఇది "ప్రతినిధి రాష్ట్ర బదిలీ" నుండి తీసుకోబడింది . కంప్యూటర్ నెట్‌వర్క్‌లో పంపిణీ చేయబడిన సిస్టమ్ యొక్క భాగాల మధ్య పరస్పర చర్య కోసం ఇది నిర్మాణ శైలి. సరళంగా చెప్పాలంటే, సిస్టమ్ యొక్క వివిధ భాగాల మధ్య పరస్పర చర్య (డేటా మార్పిడి) కోసం REST శైలిని నిర్ణయిస్తుంది, వీటిలో ప్రతి ఒక్కటి భౌతికంగా వేర్వేరు ప్రదేశాలలో ఉంటాయి. ఈ నిర్మాణ శైలి అనేది పంపిణీ చేయబడిన వ్యవస్థను రూపకల్పన చేసేటప్పుడు కట్టుబడి ఉండే స్థిరమైన పరిమితుల సమితి. ఈ పరిమితులను కొన్నిసార్లు REST యొక్క మార్గదర్శక సూత్రాలు అంటారు. చాలా లేవు, 6 మాత్రమే. మేము వాటి గురించి కొంచెం తరువాత మాట్లాడుతాము.
REST సూత్రాలను దృష్టిలో ఉంచుకుని రూపొందించబడిన అప్లికేషన్‌లు, అంటే REST పరిమితులను ఉల్లంఘించని వాటిని "RESTful" అంటారు.
REST చరిత్ర
REST అనే పదాన్ని HTTP ప్రోటోకాల్ సృష్టికర్తలలో ఒకరైన రాయ్ ఫీల్డింగ్ తన Ph.Dలో ప్రవేశపెట్టారు. 2000లో "ఆర్కిటెక్చరల్ స్టైల్స్ అండ్ ది డిజైన్ ఆఫ్ నెట్‌వర్క్-బేస్డ్ సాఫ్ట్‌వేర్ ఆర్కిటెక్చర్స్" అనే థీసిస్. REST అనే పదాన్ని ఇప్పటికీ యంగ్ అని పిలువవచ్చు, అయితే అది ప్రాతినిధ్యం వహించే భావన వరల్డ్ వైడ్ వెబ్‌లో అంతర్భాగంలో ఉంది. మేము పదం యొక్క చరిత్రలో లోతుగా డైవ్ చేయము. మీరు ప్రాథమిక మూలాల్లోకి ప్రవేశించాలనుకుంటే, ఫీల్డింగ్ యొక్క ప్రవచనాన్ని పరిశీలించండి .
REST పరిమితులు మరియు సూత్రాలు
పైన చెప్పినట్లుగా, పంపిణీ చేయబడిన సిస్టమ్ యొక్క భాగాలు ఒకదానితో ఒకటి ఎలా సంకర్షణ చెందాలో REST నిర్వచిస్తుంది. సాధారణంగా, ఇది అభ్యర్థన-ప్రతిస్పందన ప్రక్రియ ద్వారా జరుగుతుంది. అభ్యర్థనను పంపే భాగాన్ని క్లయింట్ అని పిలుస్తారు మరియు అభ్యర్థనను ప్రాసెస్ చేసే మరియు క్లయింట్‌కు ప్రతిస్పందనను పంపే భాగాన్ని సర్వర్ అంటారు. అభ్యర్థనలు మరియు ప్రతిస్పందనలు చాలా తరచుగా HTTP ప్రోటోకాల్ ద్వారా పంపబడతాయి. HTTP అంటే హైపర్‌టెక్స్ట్ ట్రాన్స్‌ఫర్ ప్రోటోకాల్. సాధారణంగా, సర్వర్ అనేది కొన్ని వెబ్ అప్లికేషన్. క్లయింట్ దాదాపు ఏదైనా కావచ్చు. ఉదాహరణకు, సర్వర్ నుండి డేటాను అభ్యర్థించే మొబైల్ యాప్. లేదా డేటాను డౌన్‌లోడ్ చేయడానికి వెబ్ పేజీ నుండి సర్వర్‌కు అభ్యర్థనలను పంపే బ్రౌజర్. అప్లికేషన్ A అనేది అప్లికేషన్ B నుండి డేటాను అభ్యర్థించవచ్చు. ఈ సందర్భంలో, A అనేది Bకి సంబంధించి క్లయింట్, మరియు B అనేది Aకి సంబంధించి సర్వర్. అదే సమయంలో, A B, C, D మొదలైన వాటి నుండి అభ్యర్థనలను ప్రాసెస్ చేయగలదు. ఈ సందర్భంలో, అప్లికేషన్ A సర్వర్ మరియు క్లయింట్ రెండూ. అంతా సందర్భాన్ని బట్టి ఉంటుంది. ఒక విషయం ఖచ్చితంగా ఉంది: అభ్యర్థనను పంపే భాగం క్లయింట్. అభ్యర్థనను స్వీకరించే, ప్రాసెస్ చేసే మరియు ప్రతిస్పందించే భాగం సర్వర్. అయితే, అభ్యర్థన-ప్రతిస్పందన ప్రక్రియ ద్వారా భాగాలు కమ్యూనికేట్ చేసే ప్రతి సిస్టమ్ RESTful వ్యవస్థ కాదు. సిస్టమ్ RESTful గా పరిగణించబడాలంటే, అది తప్పనిసరిగా ఆరు REST పరిమితులకు లోబడి ఉండాలి:
1. క్లయింట్-సర్వర్ ఆర్కిటెక్చర్
ఈ పరిమితి ఆందోళనల విభజన గురించి. డేటాను నిల్వ చేసే సర్వర్ యొక్క అవసరాల నుండి క్లయింట్ ఇంటర్ఫేస్ యొక్క అవసరాలను వేరు చేయడం అవసరం. ఈ పరిమితి క్లయింట్ కోడ్‌ను ఇతర ప్లాట్‌ఫారమ్‌లకు మరింత పోర్టబుల్‌గా చేస్తుంది మరియు సర్వర్ వైపు సరళీకృతం చేయడం వల్ల సిస్టమ్ స్కేలబిలిటీ మెరుగుపడుతుంది. "క్లయింట్" మరియు "సర్వర్" మధ్య వ్యత్యాసాన్ని గుర్తించడం వలన వాటిని ఒకదానికొకటి స్వతంత్రంగా అభివృద్ధి చేయవచ్చు.
2. స్థితిలేని
ఒక RESTful ఆర్కిటెక్చర్ కింది షరతులను నెరవేర్చడం అవసరం. అభ్యర్థనల మధ్య వ్యవధిలో, సర్వర్ క్లయింట్ యొక్క స్థితి మరియు వైస్ వెర్సా గురించి సమాచారాన్ని నిల్వ చేయకూడదు. క్లయింట్ నుండి వచ్చే అన్ని అభ్యర్థనలు తప్పనిసరిగా అభ్యర్థనను పూర్తి చేయడానికి అవసరమైన మొత్తం సమాచారాన్ని సర్వర్‌కు అందించే విధంగా కంపోజ్ చేయాలి. అందువల్ల, సర్వర్ మరియు క్లయింట్ రెండూ మునుపటి సందేశాలపై ఆధారపడకుండా ఏదైనా అందుకున్న సందేశాన్ని "అర్థం చేసుకోగలవు".
3. క్యాచీబుల్
క్లయింట్లు సర్వర్ ప్రతిస్పందనలను కాష్ చేయగలరు. ఇవి, స్పష్టంగా లేదా పరోక్షంగా కాష్ చేయబడినవి లేదా కాష్ చేయనివిగా పేర్కొనబడాలి, తద్వారా క్లయింట్లు తదుపరి అభ్యర్థనలకు ప్రతిస్పందనగా పాత లేదా తప్పు డేటాను స్వీకరించరు. సరైన కాషింగ్ కొన్ని క్లయింట్-సర్వర్ పరస్పర చర్యలను పూర్తిగా లేదా పాక్షికంగా తొలగించడానికి సహాయపడుతుంది, సిస్టమ్ పనితీరు మరియు స్కేలబిలిటీని మరింత పెంచుతుంది.
4. ఏకరీతి ఇంటర్ఫేస్
RESTful ఆర్కిటెక్చర్ యొక్క ప్రాథమిక అవసరాలు ఏకీకృత, ఏకరీతి ఇంటర్‌ఫేస్‌ను కలిగి ఉంటాయి. క్లయింట్ ఎల్లప్పుడూ అభ్యర్థనను పంపేటప్పుడు ఉపయోగించాల్సిన ఫార్మాట్ మరియు చిరునామాలను అర్థం చేసుకోవాలి మరియు సర్వర్, క్లయింట్ అభ్యర్థనలకు ప్రతిస్పందిస్తున్నప్పుడు ఉపయోగించాల్సిన ఆకృతిని కూడా అర్థం చేసుకోవాలి. ఈ స్థిరమైన క్లయింట్-సర్వర్ పరస్పర చర్య ఏమి, ఎక్కడ, ఏ రూపంలో మరియు డేటాను ఎలా పంపాలో వివరించే ఏకీకృత ఇంటర్ఫేస్.
5. పొరలు
పొరల ద్వారా, మేము నెట్‌వర్క్ యొక్క క్రమానుగత నిర్మాణాన్ని సూచిస్తాము. కొన్నిసార్లు క్లయింట్ నేరుగా సర్వర్‌తో కమ్యూనికేట్ చేయవచ్చు మరియు కొన్నిసార్లు ఇది కేవలం ఇంటర్మీడియట్ నోడ్‌తో కమ్యూనికేట్ చేస్తుంది. లోడ్ బ్యాలెన్సింగ్ మరియు పంపిణీ కాషింగ్ కారణంగా ఇంటర్మీడియట్ సర్వర్‌ల ఉపయోగం స్కేలబిలిటీని పెంచుతుంది. ఒక ఉదాహరణ ఇద్దాం. ప్రపంచవ్యాప్తంగా ప్రసిద్ధి చెందిన మొబైల్ యాప్‌ని ఊహించుకోండి. యాప్‌లో అంతర్భాగంలో చిత్రాలను లోడ్ చేయడం ఉంటుంది. దీని వినియోగదారులు మిలియన్ల సంఖ్యలో ఉన్నారు, కాబట్టి ఒకే సర్వర్ ఇంత భారీ భారాన్ని నిర్వహించదు. వ్యవస్థను పొరలుగా విభజించడం ఈ సమస్యను పరిష్కరిస్తుంది. క్లయింట్ ఇంటర్మీడియట్ నోడ్ నుండి చిత్రాన్ని అభ్యర్థించినట్లయితే, ఇంటర్మీడియట్ నోడ్ ఆ సమయంలో కనీసం లోడ్ చేయబడిన సర్వర్ నుండి చిత్రాన్ని అభ్యర్థిస్తుంది మరియు చిత్రాన్ని క్లయింట్‌కు తిరిగి ఇస్తుంది. సోపానక్రమం యొక్క ప్రతి స్థాయిలో కాషింగ్ సరిగ్గా వర్తించబడితే,
6. కోడ్ ఆన్ డిమాండ్ (ఐచ్ఛికం)
సర్వర్ నుండి ఆప్లెట్‌లు లేదా స్క్రిప్ట్‌ల రూపంలో కోడ్‌ని డౌన్‌లోడ్ చేయడం ద్వారా క్లయింట్ దాని కార్యాచరణను విస్తరించవచ్చని ఈ పరిమితి సూచిస్తుంది.
RESTful ఆర్కిటెక్చర్ యొక్క ప్రయోజనాలు
పైన పేర్కొన్న అన్ని పరిమితులకు అనుగుణంగా ఉండే అప్లికేషన్‌లు క్రింది ప్రయోజనాలను కలిగి ఉన్నాయి: విశ్వసనీయత (క్లయింట్ యొక్క స్థితిని సేవ్ చేయవలసిన అవసరం లేదు, ఇది కోల్పోవచ్చు)
మేము REST యొక్క మా అవలోకనాన్ని మూడు భాగాలుగా విభజిస్తాము:
GO TO FULL VERSION