ఒక resource URI ఒక చర్యలా కాకుండా ఒక వస్తువుకు noun-ఆధారిత pathలా చదవాలి. HTTP method ఇప్పటికే verbను అందిస్తుంది, కాబట్టి URI కేవలం resourceను స్పష్టంగా, స్థిరంగా గుర్తించాలి.
ఒక resource URI ఒక చర్యలా కాకుండా ఒక వస్తువుకు noun-ఆధారిత pathలా చదవాలి. HTTP method ఇప్పటికే verbను అందిస్తుంది, కాబట్టి URI కేవలం resourceను స్పష్టంగా, స్థిరంగా గుర్తించాలి.
GET /users/42 — GET /getUser?id=42 కాదు. method (GET) verb./users collection; /users/42 ఒక సభ్యుడు. అంతటా bahुవచనం ఉంచడం దాన్ని ఊహించదగినదిగా చేస్తుంది./users/42/orders = "user 42కు చెందిన orders".kebab-case, lowercase వాడండి. /blog-posts, /blogPosts లేదా /Blog_Posts కాదు./users?role=admin&sort=-created_at./users collection of users
/users/42 a single user
/users/42/orders orders belonging to user 42 (sub-collection)
/users/42/orders/1001 a specific order of that user
/orders/1001 same order, addressable at top level too
GET /users/42/orders?status=shipped&sort=-created_at&page=2 HTTP/1.1
Accept: application/json
ఒకటి లేదా రెండు స్థాయిలకు మించి లోతైన nestingను నివారించండి — /users/42/orders/1001/items/5/reviews పెళుసుగా మారుతుంది. ఒక orderకు దాని స్వంత ID ఉన్నాక, /orders/1001 ప్రాధాన్యత ఇవ్వండి. CRUDకు సరిపోని చర్యల కోసం (ఉదా. "send email"), controller-శైలి sub-resource అంగీకారయోగ్యం: POST /users/42/verify-email.
స్థిరమైన పేరు పెట్టడం ఒక APIని సహజంగా అనిపించేలా చేస్తుంది — /users మరియు /users/42 చూసిన developer docs చదవకుండా /products మరియు /products/99ను సరిగా ఊహించగలడు. మీరు RPC calls (/doThisThing) బదులు resources (REST మనస్తత్వం)లో ఆలోచిస్తారో లేదో అంచనా వేయడానికి ఇంటర్వ్యూయర్లు దీన్ని వాడతారు. అత్యంత సాధారణ anti-patterns — pathలో verbs, అస్థిరమైన pluralization, లోతుగా nested URLs — అన్నీ ఒక APIని నేర్చుకోవడం, నిర్వహించడం కష్టంగా చేస్తాయి, మరియు REST యొక్క uniform-interface constraintను జీర్ణించుకోని developerను సూచిస్తాయి. మంచి URI డిజైన్ ఆందోళనలను కూడా వేరుగా ఉంచుతుంది: pathలో identity, query stringలో filtering మరియు pagination, ఇది caching మరియు routingను శుభ్రంగా ఉంచుతుంది.
జూనియర్ నుండి సీనియర్ వరకు వివరణాత్మక సమాధానాలతో IT ఇంటర్వ్యూ ప్రశ్నల లైబ్రరీ.
విరాళం