REST (Representational State Transfer) networked applications के लिए एक architectural style है, जिसे Roy Fielding ने परिभाषित किया। यह कोई protocol या standard नहीं है — यह constraints का एक समूह है जिनका पालन करने पर एक API scalable, cacheable, और विकसित करने में आसान बन जाता है। एक "RESTful" API हर चीज़ को URIs द्वारा पहचाने गए resources (users, orders, products) के रूप में model करता है, और उन्हें standard HTTP methods का उपयोग करके संचालित करता है।
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
URI /users/42 resource का नाम है; GET action है; JSON representation है। यह संयोजन — path में nouns, HTTP methods के रूप में verbs — REST का हृदय है।
REST web APIs के लिए प्रमुख style है, इसलिए interviewers इस सवाल का उपयोग यह जाँचने के लिए करते हैं कि आप समझते हैं कि यह क्यों काम करता है, केवल यह नहीं कि आप इसकी वर्तनी जानते हैं। व्यवहार में सबसे ज़्यादा मायने रखने वाली दो constraints हैं statelessness (हर request स्व-निहित होती है, इसलिए आप एक load balancer के पीछे कितने भी servers लगा सकते हैं और sticky sessions के बिना horizontally scale कर सकते हैं) और uniform interface (अनुमानयोग्य, resource-oriented URLs साथ ही standard HTTP methods व status codes, जिसका मतलब है कि clients को हर endpoint के लिए custom logic की ज़रूरत नहीं)। एक मज़बूत जवाब constraints को ठोस लाभों से जोड़ता है — statelessness scaling सक्षम करता है, cacheability load घटाती है, layered system आपको CDNs व gateways डालने देता है — और यह नोट करता है कि अधिकांश "REST" APIs पूरी तरह RESTful होने के बजाय व्यावहारिक होते हैं (बहुत कम HATEOAS लागू करते हैं)। इन constraints को समझना हर दूसरे REST design निर्णय की नींव है, status codes चुनने से लेकर versioning तक।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें