REST वेब का अंतर्निहित वास्तु सिद्धांत है। वेब के बारे में आश्चर्यजनक बात यह है कि क्लाइंट (ब्राउज़र) और सर्वर क्लाइंट के बिना जटिल तरीकों से बातचीत कर सकते हैं, सर्वर और इसके संसाधनों के बारे में कुछ भी नहीं जानते हैं। मुख्य बाधा यह है कि सर्वर और क्लाइंट दोनों को उपयोग किए गए मीडिया पर सहमत होना चाहिए , जो वेब के मामले में HTML है ।
REST के सिद्धांतों का पालन करने वाले API को क्लाइंट को API की संरचना के बारे में कुछ भी जानने की आवश्यकता नहीं होती है। बल्कि, सर्वर को ग्राहक को सेवा के साथ बातचीत करने के लिए जो भी जानकारी प्रदान करने की आवश्यकता होती है। एक HTML फॉर्म इसका एक उदाहरण है: सर्वर संसाधन और आवश्यक फ़ील्ड के स्थान को निर्दिष्ट करता है। ब्राउज़र अग्रिम में नहीं जानता है कि जानकारी कहाँ जमा करनी है, और यह पहले से नहीं जानता है कि क्या जानकारी जमा करनी है। दोनों प्रकार की जानकारी पूरी तरह से सर्वर द्वारा आपूर्ति की जाती है। (इस सिद्धांत को HATEOAS : Hypermedia As The Engine of Application State कहा जाता है ।)
तो, यह HTTP पर कैसे लागू होता है , और इसे व्यवहार में कैसे लागू किया जा सकता है? HTTP क्रियाओं और संसाधनों के आसपास उन्मुख है। मुख्यधारा के उपयोग में दो क्रियाएं हैं GETऔर POSTमुझे लगता है कि हर कोई इसे पहचान लेगा। हालाँकि, HTTP मानक कई अन्य को परिभाषित करता है जैसे PUTऔर DELETE। सर्वर द्वारा दिए गए निर्देशों के अनुसार, इन क्रियाओं को संसाधनों पर लागू किया जाता है।
उदाहरण के लिए, आइए कल्पना करें कि हमारे पास एक उपयोगकर्ता डेटाबेस है जिसे एक वेब सेवा द्वारा प्रबंधित किया जाता है। हमारी सेवा JSON के आधार पर एक कस्टम हाइपरमीडिया का उपयोग करती है, जिसके लिए हम mimetype असाइन करते हैं application/json+userdb(एक application/xml+userdbऔर भी हो सकता है application/whatever+userdb- कई मीडिया प्रकार समर्थित हो सकते हैं)। क्लाइंट और सर्वर दोनों को इस प्रारूप को समझने के लिए प्रोग्राम किया गया है, लेकिन वे एक दूसरे के बारे में कुछ भी नहीं जानते हैं। जैसा कि रॉय फील्डिंग बताते हैं:
REST API को संसाधनों और ड्राइविंग एप्लिकेशन स्थिति का प्रतिनिधित्व करने के लिए उपयोग किए जाने वाले मीडिया प्रकार () को परिभाषित करने में, या मौजूदा मानक मीडिया प्रकारों के लिए विस्तारित संबंध नामों और / या हाइपरटेक्स्ट-सक्षम मार्क-अप को परिभाषित करने में अपने वर्णनात्मक प्रयास के लगभग सभी खर्च करना चाहिए।
आधार संसाधन के लिए अनुरोध /कुछ इस तरह से लौट सकता है:
निवेदन
GET /
Accept: application/json+userdb
प्रतिक्रिया
200 OK
Content-Type: application/json+userdb
{
"version": "1.0",
"links": [
{
"href": "/user",
"rel": "list",
"method": "GET"
},
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
हम अपने मीडिया के विवरण से जानते हैं कि हम "लिंक" नामक अनुभागों से संबंधित संसाधनों के बारे में जानकारी पा सकते हैं। इसे हाइपरमीडिया नियंत्रण कहा जाता है । इस मामले में, हम ऐसे अनुभाग से कह सकते हैं कि हम एक उपयोगकर्ता सूची के लिए दूसरा अनुरोध कर सकते हैं /user:
निवेदन
GET /user
Accept: application/json+userdb
प्रतिक्रिया
200 OK
Content-Type: application/json+userdb
{
"users": [
{
"id": 1,
"name": "Emil",
"country: "Sweden",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
{
"id": 2,
"name": "Adam",
"country: "Scotland",
"links": [
{
"href": "/user/2",
"rel": "self",
"method": "GET"
},
{
"href": "/user/2",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/2",
"rel": "delete",
"method": "DELETE"
}
]
}
],
"links": [
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
हम इस प्रतिक्रिया से बहुत कुछ बता सकते हैं। उदाहरण के लिए, अब हम जानते हैं कि हम ने एक नया उपयोगकर्ता बना सकते हैं POSTकरने के लिए ing /user:
निवेदन
POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Karl",
"country": "Austria"
}
प्रतिक्रिया
201 Created
Content-Type: application/json+userdb
{
"user": {
"id": 3,
"name": "Karl",
"country": "Austria",
"links": [
{
"href": "/user/3",
"rel": "self",
"method": "GET"
},
{
"href": "/user/3",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/3",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
हम यह भी जानते हैं कि हम मौजूदा डेटा को बदल सकते हैं:
निवेदन
PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Emil",
"country": "Bhutan"
}
प्रतिक्रिया
200 OK
Content-Type: application/json+userdb
{
"user": {
"id": 1,
"name": "Emil",
"country": "Bhutan",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
सूचना है कि हम अलग HTTP क्रियाओं का उपयोग करके किया जाता है ( GET, PUT, POST, DELETEआदि) के लिए इन संसाधनों में हेरफेर करने के लिए, और केवल ज्ञान हम ग्राहक की ओर से अनुमान हमारे मीडिया परिभाषा है।
आगे की पढाई:
(यह उत्तर इस बिंदु को याद करने के लिए उचित मात्रा में आलोचना का विषय रहा है। अधिकांश भाग के लिए, जो कि एक महत्वपूर्ण समालोचना है। मैंने जो मूल रूप से वर्णित किया था, वह इस बात से अधिक था कि कुछ साल पहले जब मैं आमतौर पर REST लागू किया गया था, तब तक कैसे था। पहले अपने वास्तविक अर्थ के बजाय यह लिखा है। मैंने वास्तविक अर्थ को बेहतर ढंग से प्रस्तुत करने के लिए उत्तर को संशोधित किया है।)
