वास्तव में RESTful प्रोग्रामिंग क्या है?
वास्तव में RESTful प्रोग्रामिंग क्या है?
जवाबों:
REST (प्रतिनिधि राज्य स्थानांतरण) नामक एक वास्तुशिल्प शैली की वकालत है कि वेब अनुप्रयोगों को HTTP का उपयोग करना चाहिए क्योंकि यह मूल रूप से कल्पना की गई थी । लुकअप को अनुरोधों का उपयोग करना चाहिए । , और अनुरोधों का उपयोग क्रमशः उत्परिवर्तन, निर्माण और विलोपन के लिए किया जाना चाहिए ।GET
PUT
POST
DELETE
अन्य प्रस्तोता URL को पसंद करते हैं, जैसे
http://myserver.com/catalog/item/1729
लेकिन REST आर्किटेक्चर को इन "सुंदर URL" की आवश्यकता नहीं है। एक पैरामीटर के साथ एक अनुरोध प्राप्त करें
http://myserver.com/catalog?item=1729
Restful के रूप में हर बिट है
ध्यान रखें कि जानकारी प्राप्त करने के लिए GET अनुरोधों का उपयोग कभी नहीं किया जाना चाहिए। उदाहरण के लिए, किसी आइटम को कार्ट में जोड़ने के लिए एक GET अनुरोध
http://myserver.com/addToCart?cart=314159&item=1729
उचित नहीं होगा। GET के अनुरोधों को निष्प्रभावी होना चाहिए । अर्थात्, दो बार अनुरोध जारी करना एक बार जारी करने से अलग नहीं होना चाहिए। यह वही है जो अनुरोधों को अस्वीकार्य बनाता है। एक "कार्ट में जोड़ें" अनुरोध बेकार नहीं है-इसे दो बार जारी करने से आइटम की दो प्रतियां कार्ट में जुड़ जाती हैं। इस संदर्भ में एक POST अनुरोध स्पष्ट रूप से उचित है। इस प्रकार, यहां तक कि एक RESTful वेब एप्लिकेशन को POST अनुरोधों के अपने हिस्से की आवश्यकता होती है।
यह डेविड एम। गीरी की उत्कृष्ट पुस्तक Core JavaServer फ़ेस बुक से ली गई है।
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 लागू किया गया था, तब तक कैसे था। पहले अपने वास्तविक अर्थ के बजाय यह लिखा है। मैंने वास्तविक अर्थ को बेहतर ढंग से प्रस्तुत करने के लिए उत्तर को संशोधित किया है।)
RESTful प्रोग्रामिंग के बारे में है:
Create
, Retrieve
, Update
, Delete
हो जाता है POST
, GET
, PUT
, और DELETE
। लेकिन REST HTTP तक सीमित नहीं है, यह अभी सबसे अधिक इस्तेमाल किया जाने वाला परिवहन है।अंतिम परिणाम शायद REST के परिणाम और समग्र प्रभाव के संदर्भ में सबसे महत्वपूर्ण है। कुल मिलाकर, Restful चर्चाओं का अधिकांश भाग HTTP पर केन्द्रित होता है और एक ब्राउज़र से इसका उपयोग और क्या नहीं। मैं समझता हूं कि आर। फील्डिंग ने शब्द का निर्माण तब किया जब उन्होंने आर्किटेक्चर और फैसलों का वर्णन किया जो HTTP का नेतृत्व करता है। उसकी थीसिस HTTP के बारे में संसाधनों की वास्तुकला और कैश-क्षमता के बारे में अधिक है।
यदि आप वास्तव में रुचि रखते हैं कि एक Restful वास्तुकला क्या है और यह क्यों काम करता है, तो उसकी थीसिस को कुछ बार पढ़ें और पूरी बात न केवल अध्याय 5 पढ़ें ! अगला इस बात पर ध्यान देता है कि DNS क्यों काम करता है । DNS के पदानुक्रमित संगठन और कैसे रेफरल काम करते हैं, इसके बारे में पढ़ें। फिर पढ़ें और विचार करें कि DNS कैशिंग कैसे काम करता है। अंत में, HTTP विनिर्देशों ( RFC2616 और RFC3040 विशेष रूप से) को पढ़ें और विचार करें कि कैशिंग कैसे और कैसे काम करता है। आखिरकार, यह सिर्फ क्लिक करेगा। मेरे लिए अंतिम रहस्योद्घाटन तब हुआ जब मैंने DNS और HTTP के बीच समानता देखी। इसके बाद, एसओए और संदेश पासिंग इंटरफेस क्यों स्केलेबल पर क्लिक करना शुरू होता है, यह समझना।
मुझे लगता है कि एक महत्वपूर्ण और साझा कुछ नहीं आर्किटेक्चर के वास्तुशिल्प महत्व और प्रदर्शन निहितार्थ को समझने के लिए सबसे महत्वपूर्ण चाल प्रौद्योगिकी और कार्यान्वयन विवरण पर लटकाए जाने से बचने के लिए है। संसाधनों का स्वामित्व करने वाले, उन्हें बनाने / बनाए रखने के लिए कौन जिम्मेदार है, आदि पर ध्यान केंद्रित करें, फिर अभ्यावेदन, प्रोटोकॉल और प्रौद्योगिकियों के बारे में सोचें।
PUT
और POST
वास्तव में अपडेट और क्रिएट के साथ वन-टू-वन मैप न करें। PUT
यह बनाने के लिए इस्तेमाल किया जा सकता है कि क्या ग्राहक यूआरआई होगा जो तय कर रहा है। POST
सर्वर नया URI असाइन कर रहा है, तो बनाता है।
urn:
योजना का उपयोग करता है । वैचारिक रूप से कोई अंतर नहीं है; हालांकि, एक URN की आवश्यकता है कि आपके पास URN द्वारा पहचाने गए (नामित) संसाधन का "पता लगाने" के लिए एक अलग से परिभाषित विधि है। यह सुनिश्चित करने के लिए ध्यान रखा जाना चाहिए कि आप नामित संसाधनों और उनके स्थान से संबंधित निहित युग्मन का परिचय न दें।
यह ऐसा हो सकता है जैसा दिखता है।
तीन गुणों वाला उपयोगकर्ता बनाएं:
POST /user
fname=John&lname=Doe&age=25
सर्वर जवाब देता है:
200 OK
Location: /user/123
भविष्य में, आप फिर उपयोगकर्ता जानकारी प्राप्त कर सकते हैं:
GET /user/123
सर्वर जवाब देता है:
200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>
रिकॉर्ड को संशोधित करने के लिए ( lname
और age
अपरिवर्तित रहेगा):
PATCH /user/123
fname=Johnny
रिकॉर्ड अपडेट करने के लिए (और फलस्वरूप lname
और age
NULL होगा):
PUT /user/123
fname=Johnny
PUT fname=Jonny
। यह मानों को डिफ़ॉल्ट रूप से सेट करेगा lname
और age
(शायद NULL या खाली स्ट्रिंग, और पूर्णांक 0), क्योंकि प्रदत्त प्रतिनिधित्व से डेटा के साथ PUT
पूरे संसाधन को ओवरराइट करता है । यह वह नहीं है जो "अपडेट" द्वारा निहित है, वास्तविक अपडेट करने के लिए, PATCH
विधि का उपयोग करें क्योंकि यह उन फ़ील्ड को नहीं बदलता है जो प्रतिनिधित्व में निर्दिष्ट नहीं हैं।
/user/1
कोई मतलब नहीं है और इसमें एक सूची होनी चाहिए /users
। प्रतिक्रिया एक होनी चाहिए 201 Created
और केवल उस मामले में ठीक नहीं होनी चाहिए ।
REST पर एक महान पुस्तक है REST प्रैक्टिस में ।
रीड्स रिप्रेजेंटेटिव स्टेट ट्रांसफर (REST) हैं और REST API को हाइपरटेक्स्ट-चालित होना चाहिए
मार्टिन फाउलर्स देखें रिचर्डसन परिपक्वता मॉडल (आरएमएम) एक व्याख्यात्मक सेवा के बारे में स्पष्टीकरण के लिए।
रेस्टफुल होने के लिए एक सेवा को अनुप्रयोग राज्य के इंजन के रूप में हाइपरमीडिया को पूरा करना होगा । (HATEOAS) , अर्थात, इसे RMM में स्तर 3 तक पहुंचने की जरूरत है, विवरण के लिए लेख पढ़ें या क्यूक टॉक से स्लाइड ।
HATEOAS बाधा हाइपरमीडिया के लिए एक संक्षिप्त रूप है, जो अनुप्रयोग राज्य का इंजन है। यह सिद्धांत क्लाइंट सर्वर सिस्टम के एक REST और अधिकांश अन्य रूपों के बीच महत्वपूर्ण अंतर है।
...
Restful एप्लिकेशन के क्लाइंट को इसे एक्सेस करने के लिए केवल एक ही निश्चित URL की आवश्यकता होती है। भविष्य की सभी क्रियाओं को उन URL से लौटाए गए संसाधनों के अभ्यावेदन में शामिल हाइपरमीडिया लिंक से गतिशील रूप से खोजा जाना चाहिए। मानकीकृत मीडिया प्रकारों को किसी भी क्लाइंट द्वारा समझने की अपेक्षा की जाती है जो एक RESTful API का उपयोग कर सकते हैं। (विकिपीडिया, मुक्त विश्वकोश से)
वेब फ्रेमवर्क के लिए रेस्ट लिटमस टेस्ट वेब फ्रेमवर्क के लिए एक समान परिपक्वता परीक्षण है।
शुद्ध नस्ल को स्वीकार करना: HATEOAS से प्यार करना सीखना लिंक का एक अच्छा संग्रह है।
सार्वजनिक क्लाउड के लिए REST बनाम SOAP, REST उपयोग के वर्तमान स्तरों पर चर्चा करता है।
REST और संस्करणकरण में परिवर्तनशीलता के माध्यम से एक्स्टेंसिबिलिटी, वर्जनिंग , Evolvability, आदि की चर्चा होती है
REST क्या है?
REST का अर्थ है प्रतिनिधि राज्य अंतरण। (इसे कभी-कभी "रेस्ट" कहा जाता है।) यह एक स्टेटलेस, क्लाइंट-सर्वर, कैशेबल संचार प्रोटोकॉल पर निर्भर करता है - और लगभग सभी मामलों में, HTTP प्रोटोकॉल का उपयोग किया जाता है।
REST नेटवर्कयुक्त अनुप्रयोगों को डिजाइन करने के लिए एक वास्तुकला शैली है। विचार यह है कि मशीनों के बीच कनेक्ट करने के लिए कॉर्बा, आरपीसी या एसओएपी जैसे जटिल तंत्र का उपयोग करने के बजाय, सरल HTTP का उपयोग मशीनों के बीच कॉल करने के लिए किया जाता है।
कई मायनों में, वर्ल्ड वाइड वेब ही, HTTP पर आधारित, एक REST- आधारित वास्तुकला के रूप में देखा जा सकता है। ईमानदार एप्लिकेशन डेटा (पोस्ट और / या अपडेट), डेटा पढ़ने (उदाहरण के लिए, प्रश्न बनाने) और डेटा को हटाने के लिए HTTP अनुरोधों का उपयोग करते हैं। इस प्रकार, REST सभी चार CRUD (क्रिएट / रीड / अपडेट / डिलीट) ऑपरेशंस के लिए HTTP का उपयोग करता है।
REST, RPC (दूरस्थ प्रक्रिया कॉल) और वेब सेवा (SOAP, WSDD, एट अल।) जैसे तंत्र का एक हल्का विकल्प है। बाद में, हम देखेंगे कि REST कितना सरल है।
सरल होने के बावजूद, REST पूरी तरह से चित्रित है; मूल रूप से कुछ भी नहीं है जो आप वेब सेवाओं में कर सकते हैं जो कि एक RESTful वास्तुकला के साथ नहीं किया जा सकता है। REST एक "मानक" नहीं है। उदाहरण के लिए, REST के लिए कभी भी W3C सिफ़ारिश नहीं होगी। और जब REST प्रोग्रामिंग फ्रेमवर्क होते हैं, तो REST के साथ काम करना इतना सरल होता है कि आप अक्सर पर्ल, जावा, या C # जैसी भाषाओं में मानक लाइब्रेरी सुविधाओं के साथ "अपना रोल" कर सकते हैं।
सबसे अच्छा संदर्भ में से एक मैंने पाया जब मैं आराम के सरल वास्तविक अर्थ को खोजने की कोशिश करता हूं।
REST डेटा में हेरफेर करने के लिए विभिन्न HTTP तरीकों (मुख्य रूप से GET / PUT / DELETE) का उपयोग कर रहा है।
किसी विधि (कहना /user/123/delete
) को हटाने के लिए किसी विशिष्ट URL का उपयोग करने के बजाय , आप /user/[id]
उपयोगकर्ता को जानकारी प्राप्त करने के लिए URL पर एक DELETE अनुरोध भेजेंगे , एक उपयोगकर्ता को संपादित करने के लिए, आपको एक GET अनुरोध भेजेंगे।/user/[id]
उदाहरण के लिए, इसके बजाय URL का एक सेट जो निम्नलिखित में से कुछ की तरह लग सकता है ..
GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1
आप HTTP "क्रिया" का उपयोग करते हैं और करते हैं।
GET /user/2
DELETE /user/2
PUT /user
यह प्रोग्रामिंग है जहां आपके सिस्टम का आर्किटेक्चर रॉय फील्डिंग द्वारा अपने शोध में रखी गई रीस्ट स्टाइल को फिट करता है । चूंकि यह वास्तुशिल्प शैली है जो वेब का वर्णन करती है (कम या ज्यादा), बहुत सारे लोग इसमें रुचि रखते हैं।
बोनस उत्तर: नहीं। जब तक आप एक शैक्षणिक या डिजाइनिंग वेब सेवाओं के रूप में सॉफ्टवेयर आर्किटेक्चर का अध्ययन नहीं कर रहे हैं, तब तक शब्द सुनने का कोई कारण नहीं है।
मैं कहूंगा कि RESTful प्रोग्रामिंग सिस्टम (API) बनाने के बारे में होगी जो REST आर्किटेक्चरल स्टाइल को फॉलो करती है।
मैंने डॉ। एम। एल्कस्टीन द्वारा रीस्ट के बारे में इस शानदार, लघु और आसान को समझना आसान समझा और उस आवश्यक भाग को उद्धृत किया जो आपके प्रश्न का सबसे अधिक भाग के लिए उत्तर देगा:
REST नेटवर्कयुक्त अनुप्रयोगों को डिजाइन करने के लिए एक वास्तुकला शैली है । विचार यह है कि मशीनों के बीच कनेक्ट करने के लिए कॉर्बा, आरपीसी या एसओएपी जैसे जटिल तंत्र का उपयोग करने के बजाय, सरल HTTP का उपयोग मशीनों के बीच कॉल करने के लिए किया जाता है।
- कई मायनों में, HTTP पर आधारित वर्ल्ड वाइड वेब को REST- आधारित वास्तुकला के रूप में देखा जा सकता है।
ईमानदार एप्लिकेशन डेटा (पोस्ट और / या अपडेट), डेटा पढ़ने (उदाहरण के लिए, प्रश्न बनाने) और डेटा को हटाने के लिए HTTP अनुरोधों का उपयोग करते हैं। इस प्रकार, REST सभी चार CRUD (क्रिएट / रीड / अपडेट / डिलीट) ऑपरेशंस के लिए HTTP का उपयोग करता है।
मुझे नहीं लगता कि स्टैक ओवरफ्लो के बाहर REST के बारे में न सुनने के लिए आपको बेवकूफ महसूस करना चाहिए ..., मैं उसी स्थिति में रहूंगा ;; इस सवाल पर अन्य एसओ का जवाब क्यों आरईएसटी बड़ा हो रहा है अब कुछ भावनाओं को कम कर सकता है।
अगर मैं सीधे सवाल का जवाब नहीं दे रहा हूं, तो मैं माफी चाहता हूं, लेकिन अधिक विस्तृत उदाहरणों के साथ यह सब समझना आसान है। तमाम अमूर्तता और शब्दावली के कारण फील्डिंग को समझना आसान नहीं है।
यहाँ एक अच्छा उदाहरण है:
REST और हाइपरटेक्स्ट समझाते हुए: Spam-E द स्पैम क्लीनिंग रोबोट
और इससे भी बेहतर, यहाँ सरल उदाहरणों के साथ एक स्पष्ट व्याख्या है (पावरपॉइंट अधिक व्यापक है, लेकिन आप इसे HTML संस्करण में प्राप्त कर सकते हैं:
http://www.xfront.com/Rest.ppt या http://www.xfront.com/REST.html
उदाहरणों को पढ़ने के बाद, मैं देख सकता था कि केन क्यों कह रहे हैं कि REST हाइपरटेक्स्ट-चालित है। मुझे वास्तव में यकीन नहीं है कि वह हालांकि सही है, क्योंकि वह / उपयोगकर्ता / 123 एक यूआरआई है जो एक संसाधन की ओर इशारा करता है, और मेरे लिए यह स्पष्ट नहीं है कि यह सिर्फ इसलिए अप्रतिष्ठित है क्योंकि ग्राहक इसके बारे में जानता है "आउट-ऑफ-बैंड।"
वह xfront दस्तावेज़ REST और SOAP के बीच अंतर बताता है, और यह वास्तव में बहुत उपयोगी है। जब फील्डिंग कहते हैं, " यह RPC है। यह RPC को चिल्लाता है। ", यह स्पष्ट है कि RPC RESTful नहीं है, इसलिए इसके सटीक कारण देखने के लिए यह उपयोगी है। (SOAP एक प्रकार का RPC है।)
REST क्या है?
आधिकारिक शब्दों में, आरईएसटी एक वास्तुशिल्प शैली है जिसे वर्तमान "वेब" मूल सिद्धांतों का उपयोग करके कुछ सिद्धांतों पर बनाया गया है। वेब के 5 मूल फंडामेंटल हैं जो आरईएसटी सेवाओं को बनाने के लिए उपयोग किए जाते हैं।
Communication is Done by Representation
मतलब है?
मुझे उत्तरों का एक गुच्छा दिखाई देता है जो कहते हैं कि संसाधन 123 पर उपयोगकर्ता के बारे में सब कुछ डालना "/ उपयोगकर्ता / 123" RESTful है।
रॉय फील्डिंग, जिन्होंने इस शब्द को गढ़ा था, कहते हैं कि REST API को हाइपरटेक्स्ट-चालित होना चाहिए । विशेष रूप से, "A REST API को निश्चित संसाधन नामों या पदानुक्रमों को परिभाषित नहीं करना चाहिए"।
इसलिए यदि आपका "/ user / 123" पथ क्लाइंट पर हार्डकोड किया गया है, तो यह वास्तव में Restful नहीं है। HTTP का एक अच्छा उपयोग, हो सकता है, शायद नहीं। लेकिन रेस्टफुल नहीं। यह हाइपरटेक्स्ट से आना है।
इसका उत्तर बहुत सरल है, रॉय फील्डिंग द्वारा लिखा गया एक शोध प्रबंध है।] 1 इस शोध प्रबंध में उन्होंने REST सिद्धांतों को परिभाषित किया है। यदि कोई एप्लिकेशन उन सभी सिद्धांतों को पूरा करता है, तो यह एक REST एप्लीकेशन है।
RESTful शब्द इसलिए बनाया गया था क्योंकि ppl ने REST शब्द को उनके गैर- REST अनुप्रयोग को REST के रूप में समाप्त कर दिया था। उसके बाद Restful शब्द समाप्त हो गया था। आजकल हम Web API और Hypermedia API के बारे में बात कर रहे हैं , क्योंकि तथाकथित REST अनुप्रयोगों में से अधिकांश ने समान इंटरफ़ेस बाधा के HATEOAS भाग को पूरा नहीं किया है।
बाकी बाधाएँ निम्नलिखित हैं:
क्लाइंट-सर्वर आर्किटेक्चर
इसलिए यह PUB / SUB सॉकेट के उदाहरण के साथ काम नहीं करता है, यह REQ / REP पर आधारित है।
स्टेटलेस संचार
इसलिए सर्वर क्लाइंट्स की स्थिति को बनाए नहीं रखता है। इसका अर्थ है कि आप सर्वर को साइड सेशन स्टोरेज का उपयोग नहीं कर सकते हैं और आपको हर अनुरोध को प्रमाणित करना होगा। आपके ग्राहक संभवत: एक एन्क्रिप्टेड कनेक्शन के माध्यम से मूल स्थिति हेडर भेजते हैं। (बड़े अनुप्रयोगों द्वारा कई सत्रों को बनाए रखना कठिन है।)
कैश का उपयोग यदि आप कर सकते हैं
इसलिए आपको बार-बार समान अनुरोधों की सेवा करने की आवश्यकता नहीं है।
क्लाइंट और सर्वर के बीच समान अनुबंध के रूप में समान इंटरफ़ेस
क्लाइंट और सर्वर के बीच अनुबंध सर्वर द्वारा बनाए नहीं रखा जाता है। दूसरे शब्दों में ग्राहक को सेवा के कार्यान्वयन से अलग किया जाना चाहिए। आप मानक समाधानों का उपयोग करके इस राज्य तक पहुंच सकते हैं, जैसे संसाधनों की पहचान करने के लिए आईआरआई (यूआरआई) मानक, संदेशों का आदान-प्रदान करने के लिए HTTP मानक, शरीर क्रमांकन प्रारूप, मेटाडेटा (संभवतः आरडीएफ वोकैब, माइक्रोफ़ॉर्मेट्स, आदि) का वर्णन करने के लिए मानक MIME प्रकार। संदेश के मुख्य भाग के शब्दार्थ का वर्णन करें। क्लाइंट से IRI संरचना को हटाने के लिए, आपको क्लाइंट को हाइपरमीडिया फॉर्मेट्स जैसे (HTML, JSON-LD, HAL, आदि) में हाइपरलिंक भेजना होगा। तो एक ग्राहक अपने वर्तमान लक्ष्य को प्राप्त करने के लिए उचित राज्य संक्रमणों के माध्यम से आवेदन की राज्य मशीन को नेविगेट करने के लिए हाइपरलिंक्स को सौंपे गए मेटाडेटा (संभवतः लिंक संबंध, आरडीएफ वोकैब) का उपयोग कर सकता है।
उदाहरण के लिए जब कोई ग्राहक एक webshop को ऑर्डर भेजना चाहता है, तो उसे webshop द्वारा भेजे गए प्रतिक्रियाओं में हाइपरलिंक की जांच करनी होगी। लिंक की जाँच करने से यह पाया जाता है कि http://schema.org/OrderAction के साथ वर्णित है । क्लाइंट को स्कीमा.ऑर्ग पता है, इसलिए यह समझता है कि इस हाइपरलिंक को सक्रिय करने से यह ऑर्डर भेजेगा। तो यह हाइपरलिंक को सक्रिय करता है और POST https://example.com/api/v1/order
उचित शरीर के साथ एक संदेश भेजता है । उसके बाद सेवा संदेश को संसाधित करती है और परिणाम के साथ उचित HTTP स्थिति हेडर देती है, उदाहरण के लिए 201 - created
सफलता। विस्तृत मेटाडेटा के साथ संदेशों को एनोटेट करने के लिए आरडीएफ प्रारूप का उपयोग करने के लिए मानक समाधान, उदाहरण के लिए JSON-LD एक REST वोकैब के साथ, उदाहरण के लिए हाइड्रा वोकैब के और डोमेन विशिष्ट स्वर जैसेस्कीमा.ऑर्ग या किसी अन्य लिंक किए गए डेटा वोकैब और यदि आवश्यक हो तो एक कस्टम एप्लिकेशन विशिष्ट वोकैब। अब यह आसान नहीं है, यही कारण है कि अधिकांश पीपीएल एचएएल और अन्य सरल प्रारूपों का उपयोग करते हैं जो आमतौर पर केवल आरईएसटी वोकैब प्रदान करते हैं, लेकिन कोई डेटा समर्थन नहीं।
स्केलेबिलिटी बढ़ाने के लिए एक स्तरित प्रणाली का निर्माण
आरईएसटी सिस्टम पदानुक्रमित परतों से बना है। प्रत्येक परत में घटक होते हैं जो घटकों की सेवाओं का उपयोग करते हैं जो नीचे की अगली परत में होते हैं। तो आप आसानी से नई परतों और घटकों को जोड़ सकते हैं।
उदाहरण के लिए एक क्लाइंट लेयर होती है जिसमें क्लाइंट होते हैं और उसके नीचे एक सर्विस लेयर होती है जिसमें सिंगल सर्विस होती है। अब आप उनके बीच क्लाइंट साइड कैश जोड़ सकते हैं। उसके बाद आप एक और सेवा उदाहरण और एक लोड बैलेंसर जोड़ सकते हैं, और इसी तरह ... ग्राहक कोड और सेवा कोड नहीं बदलेगा।
ग्राहक की कार्यक्षमता का विस्तार करने की मांग पर कोड
यह बाधा वैकल्पिक है। उदाहरण के लिए, आप क्लाइंट के लिए एक विशिष्ट मीडिया प्रकार के लिए एक पार्सर भेज सकते हैं, और इसी तरह ... ऐसा करने के लिए आपको क्लाइंट में एक मानक प्लगइन लोडर प्रणाली की आवश्यकता हो सकती है, या आपका क्लाइंट प्लगइन लोडर समाधान के लिए युग्मित होगा। ।
अन्य बाधाओं के परिणामस्वरूप उच्च स्केलेबल प्रणाली होती है जिसमें क्लाइंट को सेवाओं के कार्यान्वयन से हटा दिया जाता है। तो क्लाइंट पुन: प्रयोज्य हो सकते हैं, सामान्य वेब पर ब्राउज़रों की तरह। क्लाइंट और सेवाएं समान मानकों और वोकैब को साझा करते हैं, इसलिए वे इस तथ्य के बावजूद एक दूसरे को समझ सकते हैं कि क्लाइंट को सेवा के कार्यान्वयन का विवरण नहीं पता है। यह स्वचालित क्लाइंट बनाना संभव बनाता है जो अपने लक्ष्यों को प्राप्त करने के लिए आरईएसटी सेवाओं को पा सकते हैं और उनका उपयोग कर सकते हैं। लंबी अवधि में ये ग्राहक एक दूसरे से संवाद कर सकते हैं और एक दूसरे पर विश्वास कर सकते हैं, जैसे मनुष्य करते हैं। यदि हम ऐसे ग्राहकों के लिए सीखने के पैटर्न को जोड़ते हैं, तो परिणाम एकल सर्वर पार्क के बजाय मशीनों के वेब का उपयोग करके एक या अधिक एआई होगा। तो अंत में बर्नर्स ली का सपना: सिमेंटिक वेब और कृत्रिम बुद्धिमत्ता वास्तविकता होगी। इसलिए 2030 में हम स्काईनेट द्वारा समाप्त हो गए। तब तक ... ;-)
Restful (प्रतिनिधि राज्य हस्तांतरण) API प्रोग्रामिंग किसी भी प्रोग्रामिंग भाषा में 5 मूल सॉफ्टवेयर आर्किटेक्चर शैली सिद्धांतों का पालन करके वेब एप्लिकेशन लिख रहा है :
दूसरे शब्दों में, आप HTTP पर सरल पॉइंट-टू-पॉइंट नेटवर्क एप्लिकेशन लिख रहे हैं, जो GEST, POST, PUT या DELETE जैसी क्रियाओं का उपयोग करके Restful आर्किटेक्चर को लागू करते हैं जो प्रत्येक "संसाधन" इंटरफ़ेस के मानकीकरण का प्रस्ताव रखता है। यह कुछ भी नहीं है कि एक सरल और प्रभावी तरीके से वेब की वर्तमान विशेषताओं का उपयोग करना (अत्यधिक सफल, सिद्ध और वितरित वास्तुकला)। यह SOAP , CORBA और RPC जैसे अधिक जटिल तंत्रों का एक विकल्प है ।
रीस्टफुल प्रोग्रामिंग वेब आर्किटेक्चर डिजाइन के अनुरूप है और यदि इसे ठीक से लागू किया जाता है, तो यह आपको स्केलेबल वेब इन्फ्रास्ट्रक्चर का पूरा लाभ उठाने की अनुमति देता है।
अगर मुझे REST पर मूल शोध प्रबंध को केवल 3 छोटे वाक्यों को कम करना था, तो मुझे लगता है कि निम्नलिखित इसके सार को कैप्चर करता है:
इसके बाद, अनुकूलन, कोडिंग सम्मेलनों और सर्वोत्तम प्रथाओं के बारे में बहस में पड़ना आसान है।
दिलचस्प बात यह है कि शोध प्रबंध में HTTP POST, GET, DELETE, या PUT संचालन का कोई उल्लेख नहीं है। किसी "वर्दी इंटरफ़ेस" के लिए "सर्वोत्तम अभ्यास" की किसी की बाद में व्याख्या होनी चाहिए।
जब वेब सेवाओं की बात आती है, तो ऐसा लगता है कि हमें डब्ल्यूएसडीएल और एसओएपी आधारित आर्किटेक्चर को अलग करने के कुछ तरीके की आवश्यकता है जो कि इंटरफेस में काफी ओवरहेड और यकीनन बहुत अनावश्यक जटिलता जोड़ते हैं। उन्हें लागू करने के लिए अतिरिक्त रूपरेखा और डेवलपर टूल की भी आवश्यकता होती है। मुझे यकीन नहीं है कि REST सामान्य-ज्ञान इंटरफेस और अत्यधिक इंजीनियर इंटरफेस जैसे WSDL और SOAP के बीच अंतर करने के लिए सबसे अच्छा शब्द है। लेकिन हमें कुछ चाहिए।
आरईएस एक वास्तुशिल्प पैटर्न और लेखन अनुप्रयोगों की शैली है। यह संकीर्ण अर्थों में एक प्रोग्रामिंग शैली नहीं है।
यह कहना कि आप REST शैली का उपयोग करते हैं, यह कहने के समान है कि आपने एक विशेष शैली में एक घर बनाया था: उदाहरण के लिए ट्यूडर या विक्टोरियन। एक सॉफ्टवेयर शैली और ट्यूडर या विक्टोरियन के रूप में दोनों रीस्ट को एक घरेलू शैली के रूप में परिभाषित किया जा सकता है जो उन्हें बनाने वाले गुणों और बाधाओं द्वारा परिभाषित किया जा सकता है। उदाहरण के लिए REST में क्लाइंट सर्वर पृथक्करण होना चाहिए जहाँ संदेश स्व-वर्णन कर रहे हों। ट्यूडर शैली के घरों में ओवरलैपिंग गैबल और रूफ होते हैं जो सामने की ओर गैबल्स के साथ खड़ी होती हैं। रेस्ट को बनाने वाली बाधाओं और गुणों के बारे में अधिक जानने के लिए आप रॉय के शोध प्रबंध को पढ़ सकते हैं।
घरेलू शैलियों के विपरीत REST को कठिन समय लगातार और व्यावहारिक रूप से लागू करने में पड़ा है। यह जानबूझकर किया गया हो सकता है। इसके वास्तविक क्रियान्वयन को छोड़कर डिजाइनर तक। तो आप ऐसा करने के लिए स्वतंत्र हैं, जब तक आप उस अवरोध में स्थापित बाधाओं को पूरा करते हैं जो आप REST सिस्टम बना रहे हैं।
बक्शीश:
संपूर्ण वेब REST पर आधारित है (या REST वेब पर आधारित था)। इसलिए एक वेब डेवलपर के रूप में आप इसके बारे में जानना चाहते हैं, हालांकि अच्छे वेब ऐप लिखना आवश्यक नहीं है।
यहाँ REST की मेरी मूल रूपरेखा है। मैंने प्रत्येक घटक के पीछे की सोच को एक Restful वास्तुकला में प्रदर्शित करने की कोशिश की ताकि अवधारणा को समझना अधिक सहज हो। उम्मीद है कि यह कुछ लोगों के लिए REST को नष्ट करने में मदद करता है!
REST (प्रतिनिधि राज्य स्थानांतरण) एक डिज़ाइन आर्किटेक्चर है जो यह बताता है कि नेटवर्क संसाधनों (यानी नोड्स जो जानकारी साझा करते हैं) डिज़ाइन और संबोधित किए जाते हैं। सामान्य तौर पर, एक RESTful आर्किटेक्चर इसे बनाता है ताकि क्लाइंट (रिक्वेस्ट मशीन) और सर्वर (रिस्पांस मशीन) क्लाइंट के बिना डेटा को पढ़ने, लिखने और अपडेट करने का अनुरोध कर सके, ताकि यह पता चले कि सर्वर कैसे चल रहा है और सर्वर पास हो सकता है यह ग्राहक के बारे में कुछ भी जानने की आवश्यकता के बिना वापस। ठीक है, शांत ... लेकिन हम व्यवहार में यह कैसे करते हैं?
सबसे स्पष्ट आवश्यकता यह है कि किसी प्रकार की एक सार्वभौमिक भाषा होने की आवश्यकता है ताकि सर्वर क्लाइंट को बता सके कि वह अनुरोध के साथ क्या करने की कोशिश कर रहा है और सर्वर जवाब देने के लिए।
लेकिन किसी भी दिए गए संसाधन को खोजने के लिए और फिर उस ग्राहक को बताएं जहां वह संसाधन रहता है, संसाधनों पर इंगित करने का एक सार्वभौमिक तरीका होना चाहिए। यह वह जगह है जहाँ यूनिवर्सल रिसोर्स आइडेंटिफ़ायर (URI) आते हैं; वे मूल रूप से संसाधनों को खोजने के लिए अद्वितीय पते हैं।
लेकिन बाकी वास्तुकला वहाँ खत्म नहीं होती है! जबकि ऊपर हम क्या चाहते हैं की बुनियादी जरूरतों को पूरा करते हैं, हम भी एक आर्किटेक्चर रखना चाहते हैं जो किसी भी सर्वर से उच्च मात्रा ट्रैफ़िक का समर्थन करता है क्योंकि आमतौर पर कई ग्राहकों से प्रतिक्रियाएं आती हैं। इस प्रकार, हम सर्वर को पिछले अनुरोधों के बारे में जानकारी याद रखने से नहीं रोकना चाहते हैं।
इसलिए, हम प्रतिबंध लगाते हैं कि ग्राहक और सर्वर के बीच प्रत्येक अनुरोध-प्रतिक्रिया जोड़ी स्वतंत्र है, जिसका अर्थ है कि सर्वर को पिछले अनुरोधों (क्लाइंट-सर्वर इंटरैक्शन के पिछले राज्यों) के बारे में कुछ भी याद नहीं है। निवेदन। इसका मतलब यह है कि हम चाहते हैं कि हमारी बातचीत स्थिर हो।
हमारे सर्वर पर तनाव को कम करने के लिए पहले से ही दिए गए क्लाइंट के लिए हाल ही में किए गए संगणनाओं से छुटकारा पाने के लिए, REST कैशिंग की भी अनुमति देता है। मूल रूप से, कैशिंग का अर्थ क्लाइंट को प्रदान की गई प्रारंभिक प्रतिक्रिया का स्नैपशॉट लेना है। यदि क्लाइंट फिर से एक ही अनुरोध करता है, तो सर्वर क्लाइंट को शुरुआती प्रतिक्रिया बनाने के लिए आवश्यक सभी संगणनाओं को फिर से करने के बजाय स्नैपशॉट के साथ प्रदान कर सकता है। हालाँकि, चूंकि यह स्नैपशॉट है, अगर स्नैपशॉट की समय सीमा समाप्त नहीं हुई है - सर्वर अग्रिम में एक समाप्ति समय निर्धारित करता है - और प्रतिक्रिया प्रारंभिक कैश के बाद से अपडेट की गई है (यानी अनुरोध कैश्ड प्रतिक्रिया की तुलना में एक अलग उत्तर देगा) , जब तक कि कैश समाप्त नहीं हो जाता है (या कैश साफ़ हो जाता है) क्लाइंट को अपडेट नहीं दिखाई देगा और प्रतिक्रिया फिर से खरोंच से प्रदान की जाती है।
आखिरी बात जो आप अक्सर यहाँ के वास्तुशिल्प के बारे में बताएंगे, वह यह है कि वे स्तरित हैं। हम वास्तव में पहले से ही ग्राहक और सर्वर के बीच बातचीत की हमारी चर्चा में इस आवश्यकता पर चर्चा कर रहे हैं। मूल रूप से, इसका मतलब है कि हमारे सिस्टम में प्रत्येक परत केवल आसन्न परतों के साथ बातचीत करती है। इसलिए हमारी चर्चा में, क्लाइंट लेयर हमारे सर्वर लेयर (और इसके विपरीत) के साथ इंटरैक्ट करता है, लेकिन अन्य सर्वर लेयर्स हो सकती हैं जो प्राथमिक सर्वर प्रोसेस को रिक्वेस्ट करने में मदद करती हैं जिससे क्लाइंट सीधे संवाद नहीं करता। बल्कि, सर्वर अनुरोध पर आवश्यक रूप से गुजरता है।
अब, अगर यह सब परिचित लगता है, तो महान है। हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP), जो वर्ल्ड वाइड वेब के माध्यम से संचार प्रोटोकॉल को परिभाषित करता है, Restful वास्तुकला की अमूर्त धारणा (या REST वर्ग का एक उदाहरण यदि आप मेरे जैसे ओओपी कट्टरपंथी हैं) का कार्यान्वयन है। REST के इस कार्यान्वयन में, क्लाइंट और सर्वर GET, POST, PUT, DELETE, आदि के माध्यम से बातचीत करते हैं, जो सार्वभौमिक भाषा का हिस्सा हैं और संसाधन URL का उपयोग करने के लिए इंगित किए जा सकते हैं।
मुझे लगता है कि स्टेटफुल का बिंदु एक स्टेटमेंट ट्रांसपोर्ट परत के रूप में इंटरनेट (प्रोटोकॉल) का उपयोग करते समय एक उच्च परत में राज्य की स्थिति का अलगाव है । अधिकांश अन्य दृष्टिकोण चीजों को मिलाते हैं।
इंटरनेट युग में प्रोग्रामिंग के मूलभूत परिवर्तनों को संभालने के लिए यह सबसे अच्छा व्यावहारिक तरीका है। मूलभूत परिवर्तनों के बारे में, एरिक मीजेर के यहाँ शो पर एक चर्चा है: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 । वह इसे पांच प्रभावों के रूप में सारांशित करता है, और एक समाधान को प्रोग्रामिंग भाषा में डिज़ाइन करके समाधान प्रस्तुत करता है। समाधान, भाषा की परवाह किए बिना, प्लेटफ़ॉर्म या सिस्टम स्तर में भी प्राप्त किया जा सकता है। बाकी को मौजूदा समाधानों में से एक के रूप में देखा जा सकता है जो मौजूदा अभ्यास में बहुत सफल रहा है।
आरामदायक शैली के साथ, आप एक अविश्वसनीय इंटरनेट पर एप्लिकेशन की स्थिति को प्राप्त और हेरफेर करते हैं। यदि यह सही और वर्तमान स्थिति प्राप्त करने के लिए वर्तमान ऑपरेशन में विफल रहता है, तो एप्लिकेशन को जारी रखने में सहायता के लिए इसे शून्य-सत्यापन प्रिंसिपल की आवश्यकता है। यदि यह राज्य में हेरफेर करने में विफल रहता है, तो यह आमतौर पर चीजों को सही रखने के लिए पुष्टि के कई चरणों का उपयोग करता है। इस अर्थ में, आराम स्वयं एक संपूर्ण समाधान नहीं है, इसे अपने काम का समर्थन करने के लिए वेब एप्लिकेशन स्टैक के अन्य भाग में कार्यों की आवश्यकता है।
इस दृष्टिकोण को देखते हुए, बाकी शैली वास्तव में इंटरनेट या वेब एप्लिकेशन से जुड़ी नहीं है। यह प्रोग्रामिंग की कई स्थितियों का एक मौलिक समाधान है। यह या तो सरल नहीं है, यह सिर्फ इंटरफ़ेस को वास्तव में सरल बनाता है, और अन्य प्रौद्योगिकियों के साथ आश्चर्यजनक रूप से अच्छी तरह से मुकाबला करता है।
बस मेरा 2 सी।
संपादित करें: दो और महत्वपूर्ण पहलू:
स्टेटलेसनेस भ्रामक है। यह बाकी एपीआई के बारे में है, न कि एप्लिकेशन या सिस्टम के बारे में। सिस्टम को स्टेटफुल होना चाहिए। रेस्टफुल डिजाइन स्टेटलेस सिस्टम पर आधारित होता है जो स्टेटलेस एपीआई पर आधारित होता है। एक और QA के कुछ उद्धरण :
यह आश्चर्यजनक रूप से लंबी "चर्चा" है और अभी तक कम से कम कहने के लिए काफी भ्रामक है।
IMO:
1) एक बड़ा संयुक्त और बहुत सारे बीयर के बिना, आराम से प्रोग्राम करने जैसी कोई चीज नहीं है :)
2) प्रतिनिधि राज्य स्थानांतरण (आरईएसटी) एक क्षेत्रीय शैली है जो रॉय फील्डिंग के शोध प्रबंध में निर्दिष्ट है । इसमें कई तरह की अड़चनें हैं। यदि आपकी सेवा / ग्राहक उनका सम्मान करते हैं तो यह RESTful है। यह बात है।
आप (काफी) बाधाओं को संक्षेप में बता सकते हैं:
एक और बहुत अच्छी पोस्ट है जो चीजों को अच्छी तरह से समझाती है।
बहुत सारे उत्तर, मान्य जानकारी को कॉपी / पेस्ट करते हैं और कुछ भ्रम जोड़ते हैं। लोग यहां स्तरों के बारे में बात करते हैं, RESTFul URI के बारे में (ऐसी कोई बात नहीं है!), HTTP तरीकों को लागू करें GET, POST, PUT ... REST उस बारे में या केवल उसी के बारे में नहीं है।
उदाहरण के लिंक के लिए - खूबसूरती से दिखने वाली एपीआई के लिए अच्छा है लेकिन अंत में क्लाइंट / सर्वर को आपके द्वारा प्राप्त लिंक की वास्तव में परवाह नहीं है / भेजना यह ऐसी सामग्री है जो मायने रखती है।
अंत में कोई भी Restful ग्राहक किसी भी Restful सेवा का उपभोग करने में सक्षम होना चाहिए जब तक कि सामग्री प्रारूप ज्ञात नहीं हो जाता है।
पुराना सवाल, जवाब देने का नया तरीका। इस अवधारणा के बारे में कई गलत धारणाएं हैं। मैं हमेशा याद रखने की कोशिश करता हूं:
मैं आराम करने वाली प्रोग्रामिंग को परिभाषित करता हूं
एक अनुप्रयोग आराम कर रहा है अगर यह मीडिया प्रदान करता है, तो ग्राहक को समझने वाले संसाधन (डेटा + राज्य संक्रमण नियंत्रण के संयोजन) प्रदान करता है
एक आराम करने वाला प्रोग्रामर बनने के लिए आपको ऐसे एप्लिकेशन बनाने की कोशिश करनी चाहिए जो अभिनेताओं को चीजें करने की अनुमति दें। सिर्फ डेटाबेस को उजागर नहीं कर रहा है।
राज्य संक्रमण नियंत्रण केवल तभी समझ में आता है जब ग्राहक और सर्वर संसाधन के मीडिया प्रकार के प्रतिनिधित्व पर सहमत होते हैं। अन्यथा यह जानने का कोई तरीका नहीं है कि एक नियंत्रण क्या है और एक नियंत्रण निष्पादित करने के लिए क्या और कैसे नहीं है। IE अगर ब्राउज़र <form>
html में टैग नहीं जानते थे, तो आपके ब्राउज़र में संक्रमण राज्य में जमा करने के लिए आपके पास कुछ भी नहीं होगा।
मैं स्वयं को बढ़ावा देने के लिए नहीं देख रहा हूं, लेकिन मैं अपनी बात में इन विचारों पर बहुत गहराई से विस्तार करता हूं http://techblog.bodybuild.com/2016/01/video-what-is-restful-200.html ।
मेरी बात का एक अंश अक्सर रिचर्डसन मैच्योरिटी मॉडल के बारे में बताया गया है, मुझे स्तरों पर विश्वास नहीं है, आप या तो रेस्टफुल (लेवल 3) हैं या आप नहीं हैं, लेकिन मुझे इस बारे में कॉल करना पसंद है कि प्रत्येक स्तर क्या है आप के लिए अपने रास्ते पर करने के लिए करता है
REST 6 वास्तु बाधाओं को परिभाषित करता है जो किसी भी वेब सेवा को बनाते हैं - एक सच्चा RESTful API ।
REST === HTTP सादृश्य तब तक सही नहीं है जब तक आप इस तथ्य पर जोर न दें कि यह "MUST" होना चाहिए HATEOAS ।
रॉय ने खुद यहां सफाई दी ।
REST API को प्रारंभिक URI (बुकमार्क) से परे कोई पूर्व ज्ञान के साथ दर्ज किया जाना चाहिए और मानकीकृत मीडिया प्रकारों का सेट जो कि उपयुक्त श्रोताओं के लिए उपयुक्त हो (अर्थात, किसी भी क्लाइंट द्वारा समझा जा सकता है जो एपीआई का उपयोग कर सकता है)। उस बिंदु से, सभी एप्लिकेशन स्टेट ट्रांज़िशन को क्लाइंट-प्रदान किए गए विकल्पों के क्लाइंट चयन द्वारा संचालित किया जाना चाहिए जो प्राप्त अभ्यावेदन में मौजूद हैं या उन अभ्यावेदन के उपयोगकर्ता के हेरफेर से निहित है। संक्रमण को मीडिया प्रकारों और संसाधन संचार तंत्र के ग्राहक के ज्ञान को निर्धारित (या सीमित) करके किया जा सकता है, दोनों को ऑन-द-फ्लाई (जैसे, कोड-ऑन-डिमांड) में सुधार किया जा सकता है।
[यहाँ असफलता का अर्थ है कि बाहर की जानकारी हाइपरटेक्स्ट के बजाय बातचीत चला रही है।]
REST एक वास्तुशिल्प शैली है जो वेब-मानकों और HTTP प्रोटोकॉल (2000 में शुरू की गई) पर आधारित है।
REST आधारित वास्तुकला में, सब कुछ एक संसाधन (उपयोगकर्ता, आदेश, टिप्पणियाँ) है। HTTP मानक विधियों (GET, PUT, PATCH, DELETE etc) के आधार पर एक सामान्य इंटरफ़ेस के माध्यम से एक संसाधन तक पहुँचा जाता है।
REST आधारित आर्किटेक्चर में आपके पास REST सर्वर होता है जो संसाधनों तक पहुँच प्रदान करता है। एक REST क्लाइंट REST संसाधनों तक पहुँच सकता है और संशोधित कर सकता है।
हर संसाधन को HTTP के सामान्य संचालन का समर्थन करना चाहिए। संसाधन वैश्विक आईडी (जो आमतौर पर यूआरआई हैं) द्वारा पहचाने जाते हैं।
REST यह अनुमति देता है कि संसाधनों के अलग-अलग निरूपण हैं, जैसे, पाठ, XML, JSON आदि। REST क्लाइंट HTTP प्रोटोकॉल (सामग्री वार्ता) के माध्यम से एक विशिष्ट प्रतिनिधित्व के लिए कह सकता है।
HTTP तरीके:
REST आधारित आर्किटेक्चर में PUT, GET, POST और DELETE विधियां विशिष्ट हैं। निम्न तालिका इन कार्यों का स्पष्टीकरण देती है।
REST का अर्थ है प्रतिनिधि राज्य हस्तांतरण ।
यह एक स्टेटलेस, क्लाइंट-सर्वर, कैशेबल संचार प्रोटोकॉल पर निर्भर करता है - और लगभग सभी मामलों में, HTTP प्रोटोकॉल का उपयोग किया जाता है।
REST का उपयोग अक्सर मोबाइल एप्लिकेशन, सोशल नेटवर्किंग वेब साइटों, मैशप टूल और स्वचालित व्यावसायिक प्रक्रियाओं में किया जाता है। REST शैली इस बात पर जोर देती है कि क्लाइंट और सेवाओं के बीच परस्पर क्रिया सीमित संख्या में होती है (क्रिया)। लचीलेपन को संसाधन (संज्ञा) उनके स्वयं के अद्वितीय सार्वभौमिक संसाधन संकेतक (यूआरआई) प्रदान करके प्रदान किया जाता है।
बातचीत केवल सूचनाओं के आदान-प्रदान से अधिक है । एक प्रोटोकॉल वास्तव में डिज़ाइन किया गया है ताकि कोई बात न हो। प्रत्येक पार्टी को पता है कि उनका विशेष काम क्या है क्योंकि यह प्रोटोकॉल में निर्दिष्ट है। प्रोटोकॉल संभावित कार्यों में किसी भी परिवर्तन होने की कीमत पर शुद्ध सूचना विनिमय के लिए अनुमति देते हैं। दूसरी ओर, बात करते हुए, एक पक्ष को यह पूछने की अनुमति मिलती है कि दूसरे पक्ष से और क्या कार्यवाही की जा सकती है। वे दो बार एक ही प्रश्न पूछ सकते हैं और दो अलग-अलग उत्तर प्राप्त कर सकते हैं, क्योंकि अन्य पार्टी का राज्य अंतरिम में बदल सकता है। बात कर रहे हैं अन्य वास्तुकला । फील्डिंग की थीसिस वास्तुकला को निर्दिष्ट करती है कि किसी को मशीनों को करने की अनुमति देने के लिए पालन करना होगा बजाय एक दूसरे बात करने कीसंवाद करें ।
"रेस्टफुल प्रोग्रामिंग" प्रति se जैसी धारणा नहीं है। इसे बेहतर Restful प्रतिमान या इससे भी बेहतर Restful वास्तुकला कहा जाएगा। यह एक प्रोग्रामिंग भाषा नहीं है। यह एक प्रतिमान है।
कंप्यूटिंग में, प्रतिनिधित्वात्मक राज्य हस्तांतरण (REST) एक वास्तुशिल्प शैली है जिसका उपयोग वेब विकास के लिए किया जाता है।
आराम की बात यह है कि अगर हम बुनियादी कार्यों (http क्रिया) के लिए एक सामान्य भाषा का उपयोग करने के लिए सहमत हैं, तो बुनियादी ढांचे को उन्हें समझने और उन्हें ठीक से अनुकूलित करने के लिए कॉन्फ़िगर किया जा सकता है, उदाहरण के लिए, कैशिंग हेडर का उपयोग करके कैशिंग को बिल्कुल लागू करने के लिए। स्तरों।
ठीक से लागू किए गए आराम से GET ऑपरेशन के साथ, यदि आपके सर्वर की DB, आपके सर्वर का मेमेक, CDN, प्रॉक्सी का कैश, आपके ब्राउज़र का कैश या आपके ब्राउज़र का स्थानीय संग्रहण से जानकारी आती है, तो इससे कोई फर्क नहीं पड़ता। उपवास, सबसे आसानी से उपलब्ध स्रोत तक उपयोग किया जा सकता है।
यह कहते हुए कि रेस्ट केवल एक सिंटैक्टिक परिवर्तन है, जो कि जीईटी अनुरोधों को एक्शन पैरामीटर के साथ उपयोग करने से उपलब्ध http क्रियाओं के उपयोग से ऐसा लगता है कि इसका कोई लाभ नहीं है और यह पूरी तरह से कॉस्मेटिक है। बिंदु एक ऐसी भाषा का उपयोग करना है जिसे श्रृंखला के प्रत्येक भाग द्वारा समझा और अनुकूलित किया जा सकता है। यदि आपके GET ऑपरेशन में साइड इफेक्ट्स के साथ एक कार्रवाई है, तो आपको सभी HTTP कैशिंग को छोड़ना होगा या आप असंगत परिणामों के साथ समाप्त होंगे।
एपीआई परीक्षण क्या है ?
एपीआई परीक्षण, एपीआई को कॉल भेजने और उपज प्राप्त करने के लिए प्रोग्रामिंग का उपयोग करता है। यह परीक्षण एक ब्लैक बॉक्स के रूप में परीक्षण के तहत खंड का संबंध है। एपीआई परीक्षण का उद्देश्य एक आवेदन में इसके समन्वय से पहले भाग के सही निष्पादन और दोषपूर्ण उपचार की पुष्टि करना है।
बाकी एपीआई
बाकी: प्रतिनिधि राज्य स्थानांतरण।
4 आमतौर पर इस्तेमाल किया एपीआई तरीके: -
मैन्युअल रूप से एपीआई परीक्षण करने के लिए कदम: -
API का उपयोग मैन्युअल रूप से करने के लिए, हम ब्राउज़र आधारित REST API प्लग इन का उपयोग कर सकते हैं।
यह हर जगह बहुत कम उल्लिखित है, लेकिन रिचर्डसन की परिपक्वता मॉडल वास्तव में जज करने के लिए सबसे अच्छा तरीकों में से एक है कि कोई व्यक्ति कितना आराम करता है। इसके बारे में यहाँ और अधिक:
मैं कहूंगा कि REST समझने में एक महत्वपूर्ण बिल्डिंग ब्लॉक एंडपॉइंट या मैपिंग में निहित है, जैसे /customers/{id}/balance
।
आप अपने डेटाबेस / सर्वर (बैक-एंड) के लिए वेबसाइट (फ्रंट-एंड) से कनेक्टिंग पाइपलाइन होने के रूप में इस तरह के एक समापन बिंदु की कल्पना कर सकते हैं। उनका उपयोग करते हुए, फ्रंट-एंड बैक-एंड ऑपरेशन कर सकता है जो आपके एप्लिकेशन में किसी भी REST मैपिंग के संबंधित तरीकों में परिभाषित किए गए हैं।