8.1 రిమోట్ API విధానం
క్లయింట్-సర్వర్ నిర్మాణాన్ని నిర్మించేటప్పుడు ప్రోగ్రామర్లు అందరూ ఒకే పొరపాటు చేస్తారు. వారు సర్వర్‌కు అభ్యర్థనలను మెథడ్ కాల్‌లుగా పరిగణించడం ప్రారంభిస్తారు .
మీరు సర్వర్‌లో నివేదిక ఉత్పత్తి ప్రక్రియను ప్రారంభించాలనుకుంటున్నారు, దీనికి ఇలాంటి అభ్యర్థనను ఎందుకు పంపకూడదు:
http://server.com/startDocumentGeneration?paramsమరియు నివేదిక పూర్తయిన తర్వాత దాన్ని డౌన్‌లోడ్ చేయడం ఎలా? దీన్ని చేయడానికి, మేము మరొక పద్ధతిని వ్రాస్తాము:
http://server.com/getDocumentసర్వర్ HttpSessionమా పత్రంపై సమాచారాన్ని స్టోర్ చేస్తుంది మరియు పత్రం రూపొందించబడిన వెంటనే, సర్వర్ దానిని తిరిగి ఇస్తుంది.
గొప్ప విధానం. లేదా?
విధానం నిజంగా భయంకరమైనది. విషయం ఏమిటంటే సర్వర్ తప్పనిసరిగా డాక్యుమెంట్ నంబర్‌ను గుర్తుంచుకోవాలి. మరో మాటలో చెప్పాలంటే, కొత్త పద్ధతి కాల్‌లను సరిగ్గా ప్రాసెస్ చేయడానికి, సర్వర్ మునుపటి పద్ధతులకు కాల్ చేసిన ఫలితాలను గుర్తుంచుకోవాలి.
వెబ్‌లో, ఇది పెద్ద సమస్య. ఇంటర్నెట్ అదృశ్యం కావచ్చు, బ్రౌజర్ మూసివేయవచ్చు. పేజీని మళ్లీ లోడ్ చేయవచ్చు లేదా అనుకోకుండా లింక్‌పై క్లిక్ చేయడం మొదలైనవి చేయవచ్చు. మరియు సర్వర్ మునుపటి వినియోగదారు అభ్యర్థనల నుండి మెగాబైట్ల డేటాను నిల్వ చేయడం కొనసాగిస్తుంది ...
సర్వర్‌తో సౌకర్యవంతమైన పని కోసం, మీరు ఎల్లప్పుడూ సర్వర్‌కి మునుపటి అభ్యర్థనల డేటాను కలిగి ఉంటారని మీరు ఆశించలేరు.
సర్వర్ యొక్క పద్ధతులను ఎలా కాల్ చేయాలి? సరైన సమాధానం భయంకరంగా ఉంటుంది: మార్గం లేదు!
8.2 REST విధానం
ప్రోగ్రామర్లు బేసిక్స్‌కి తిరిగి వెళ్లి, మొదట అభ్యర్థన సర్వర్‌లోని ఫైల్‌కు మార్గాన్ని కలిగి ఉందని గుర్తు చేసుకున్నారు:
http://server.com/path?paramsమరియు మేము ఈ విధానాన్ని గరిష్టంగా ఉపయోగించాలని నిర్ణయించుకున్నాము.
ఇప్పుడు సర్వర్ అనేది చెట్టు రూపంలో బయట కనిపించే డేటా రిపోజిటరీగా పరిగణించబడుతుంది .
మీరు వినియోగదారులందరి జాబితాను పొందాలనుకుంటే, ప్రశ్నకు కాల్ చేయండి:
http://server.com/usersమీరు వినియోగదారు 113లో డేటాను పొందాలనుకుంటే, ప్రశ్నను అమలు చేయండి:
http://server.com/users/113మరియు అందువలన న, అన్ని అదే పంథాలో.
మరోసారి, సర్వర్ ఒక చెట్టు రూపంలో బయట కనిపించే డేటా రిపోజిటరీగా కనిపిస్తుంది.
డేటాను స్వీకరించవచ్చు - అభ్యర్థనలను పొందండి , సవరించిన పోస్ట్ అభ్యర్థన మరియు తొలగించబడినది - డిలీట్ అభ్యర్థన .
8.3 రాష్ట్రం లేదు
క్లయింట్ మరియు సర్వర్ మధ్య పరస్పర చర్య యొక్క REST ప్రోటోకాల్‌కు క్రింది షరతు అవసరం: క్లయింట్ నుండి అభ్యర్థనల మధ్య వ్యవధిలో, క్లయింట్ స్థితి గురించి ఎటువంటి సమాచారం సర్వర్‌లో నిల్వ చేయబడదు.
క్లయింట్ నుండి అన్ని అభ్యర్థనలు తప్పనిసరిగా ప్రతిసారీ అభ్యర్థనను నెరవేర్చడానికి అవసరమైన మొత్తం సమాచారాన్ని సర్వర్ అందుకునే విధంగా రూపొందించబడాలి . సెషన్ స్థితి క్లయింట్ వైపు సేవ్ చేయబడింది.
క్లయింట్ అభ్యర్థనల ప్రాసెసింగ్ సమయంలో, క్లయింట్ పరివర్తన స్థితిలో ఉన్నట్లు పరిగణించబడుతుంది. ప్రతి వ్యక్తిగత అప్లికేషన్ స్థితిని క్లయింట్ తదుపరిసారి హిట్ చేసినప్పుడు సూచించబడే లింక్‌ల ద్వారా సూచించబడుతుంది.
8.4 ఇంటర్ఫేస్ ఏకరూపత
సర్వర్ నుండి వస్తువులను తిరిగి పొందడానికి ఉపయోగించే అన్ని మార్గాలు ప్రమాణీకరించబడ్డాయి. ఇది చాలా సౌకర్యవంతంగా ఉంటుంది, ప్రత్యేకించి మీరు ఇతర REST సర్వర్‌ల నుండి డేటాను పొందుతున్నట్లయితే.
అన్ని ఆబ్జెక్ట్ ఇంటర్‌ఫేస్‌లు తప్పనిసరిగా మూడు షరతులకు అనుగుణంగా ఉండాలి:
వనరుల గుర్తింపు
URIని ఉపయోగించి అభ్యర్థనలలో అన్ని వనరులు గుర్తించబడతాయి. సర్వర్‌లోని వనరులు క్లయింట్‌లకు తిరిగి వచ్చే వీక్షణల నుండి వేరుగా ఉంటాయి. ఉదాహరణకు, సర్వర్ డేటాబేస్ నుండి డేటాను HTML, XML లేదా JSONగా పంపవచ్చు, వీటిలో ఏదీ సర్వర్‌లోని నిల్వ రకం కాదు.
ఒక వీక్షణ ద్వారా వనరులను మార్చడం
క్లయింట్ మెటాడేటాతో సహా వనరు యొక్క ప్రాతినిధ్యాన్ని నిల్వ చేస్తే, సర్వర్‌లో వనరును సవరించడానికి లేదా తొలగించడానికి తగినంత సమాచారం ఉంటుంది.
"స్వీయ-వర్ణన" సందేశాలు
ప్రతి సందేశం దానిని ఎలా నిర్వహించాలో అర్థం చేసుకోవడానికి తగినంత సమాచారాన్ని కలిగి ఉంటుంది. ఉదాహరణకు, మీకు వినియోగదారు గురించి సమాచారం కావాలంటే, సర్వర్ మీకు JSON ఆబ్జెక్ట్‌ని అందిస్తుంది, అక్కడ పేరు, చిరునామా ఫీల్డ్‌లు ఉంటాయి.
ప్రతిస్పందనలో మొదటి సంఖ్య వయస్సు, మరియు రెండవది పుట్టిన తేదీ అని క్లయింట్ తెలుసుకోవలసిన పరిస్థితి ఉండకూడదు.
8.5 కాషింగ్
డేటా అభ్యర్థనలు HTTP ప్రోటోకాల్ ద్వారా చేయబడతాయని REST విధానం ఊహిస్తుంది. అందువల్ల, GET అభ్యర్థనకు కాల్ చేయడం ద్వారా వస్తువులు పొందబడతాయి. GET అభ్యర్థన ద్వారా స్వీకరించబడిన అన్ని వనరుల వలె, అవి HTTP వనరులను కాషింగ్ చేయడానికి అన్ని నియమాలకు లోబడి ఉంటాయి.
అంటే, REST API ద్వారా స్వీకరించబడిన డేటా వెబ్ సర్వర్‌లలో ఏదైనా స్టాటిక్ రిసోర్స్‌ల మాదిరిగానే కాష్ చేయబడుతుంది. అందం :)