सवाल रीस्टफुल प्रोग्रामिंग वास्तव में क्या है?


रीस्टफुल प्रोग्रामिंग वास्तव में क्या है?


3630
2018-03-22 14:45


मूल


निम्न लिंक पर भी जवाब देखें stackoverflow.com/a/37683965/3762855 - Ciro Corvino
आरईएसटी अब थोड़ा पुराना हो सकता है;) youtu.be/WQLzZf34FJ8 - Vlady Veselinov
साथ ही, इस लिंक को कुछ और जानकारी के लिए देखें news.ycombinator.com/item?id=3538585 - Ashraf.Shk786
यहां स्वीकृत उत्तर में सुधार। stackoverflow.com/questions/19843480/...  या इधर roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven  या इधर web.archive.org/web/20130116005443/http://tomayko.com/writings/... - kushalvm
@ OLIVER.KOO अच्छा अवलोकन। यह सिर्फ इतना है कि मैंने इसे एक समय में पूछा जब यह एक नई बात थी। इसे बहुत से फेंक दिया गया था लेकिन बहुत से लोगों को पता नहीं था कि यह क्या था। कम से कम मैंने नहीं किया, और ऐसा लगता है कि मुझसे पूछने से उनकी मदद मिली है क्योंकि वे भी जानना चाहते थे। - hasen


जवाब:


एक वास्तुशिल्पीय शैली बुलाया आरईएसटी (प्रतिनिधि राज्य स्थानांतरण) वकालत करता है कि वेब अनुप्रयोगों को HTTP का उपयोग करना चाहिए जैसा कि यह था मूल रूप से कल्पना की। लुकअप का उपयोग करना चाहिए GET अनुरोध। PUT, POST, तथा DELETE अनुरोध के लिए इस्तेमाल किया जाना चाहिए क्रमशः उत्परिवर्तन, निर्माण, और हटाना

आरईएसटी समर्थक यूआरएल का समर्थन करते हैं, जैसे कि

http://myserver.com/catalog/item/1729

लेकिन आरईएसटी आर्किटेक्चर को इन "सुंदर यूआरएल" की आवश्यकता नहीं है। पैरामीटर के साथ एक अनुरोध प्राप्त करें

http://myserver.com/catalog?item=1729

रीस्टफुल के रूप में हर बिट है।

ध्यान रखें कि जानकारी अपडेट करने के लिए अनुरोधों का कभी भी उपयोग नहीं किया जाना चाहिए। उदाहरण के लिए, एक कार्ट में एक आइटम जोड़ने के लिए एक GET अनुरोध

http://myserver.com/addToCart?cart=314159&item=1729

उचित नहीं होगा। अनुरोध प्राप्त होना चाहिए idempotent। यही है, दो बार अनुरोध जारी करना एक बार इसे जारी करने से अलग नहीं होना चाहिए। अनुरोधों को कैश करने योग्य बनाता है। एक "कार्ट में जोड़ें" अनुरोध बेवकूफ नहीं है-इसे दो बार जारी करने से आइटम की दो प्रतियां कार्ट में जोड़ती हैं। इस संदर्भ में एक POST अनुरोध स्पष्ट रूप से उपयुक्त है। इस प्रकार, यहां तक ​​कि एक विश्वसनीय वेब एप्लिकेशन POST अनुरोधों के अपने हिस्से की जरूरत है।

यह उत्कृष्ट पुस्तक से लिया जाता है कोर जावा सर्वर चेहरे डेविड एम। गेरी द्वारा पुस्तक।


541
2018-04-15 11:26



लिस्िटिंग उपलब्ध बेवकूफ संचालन: प्राप्त करें (सुरक्षित), पुट और हटाएं (इस लिंक में अपवाद का उल्लेख restapitutorial.com/lessons/idempotency.html) है। सुरक्षित और बेवकूफ तरीकों के लिए अतिरिक्त संदर्भ w3.org/Protocols/rfc2616/rfc2616-sec9.html - Abhijeet
ए) जीईटी के बारे में महत्वपूर्ण बात सुरक्षितता है, बेवकूफी नहीं, बी) @ अभजीत: 2014 में आरएफसी 2616 अप्रचलित कर दिया गया है; आरएफ 7230 एफ देखें। - Julian Reschke
ये गलत है। आरईएसटी की सही व्याख्या के लिए इसे पढ़ें roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven  या यह stackoverflow.com/questions/19843480/... - kushalvm
@ कुशलवम आरईएसटी की शैक्षिक परिभाषा अभ्यास में प्रयोग नहीं की जाती है। - Elliott Beach
आरईएसटी का उद्देश्य कभी भी वेब एपीआई के लिए इस्तेमाल नहीं किया गया था, केवल स्थिर संसाधनों के लिए, और वे कर रहे हैं हाइपरटेक्स्ट संचालित। हालांकि, फील्डिंग, अपने सभी अकादमिक नैतिकता में, सोचा कि उन्हें सीधे इस ब्राउज़र से सभी HTTP क्रियाओं की मदद से बनाए रखा जाएगा, जो कि किसी भी दर या रूप में व्यावहारिक नहीं है। आरईएसटी बेकार buzzwords के गुच्छा के अलावा कुछ भी नहीं है और ASAP छोड़ दिया जाना चाहिए। - Vadim Ferderer


आराम वेब का अंतर्निहित वास्तुशिल्प सिद्धांत है। वेब के बारे में आश्चर्यजनक बात यह है कि क्लाइंट (ब्राउज़र) और सर्वर क्लाइंट के बिना जटिल तरीके से बातचीत कर सकते हैं, बिना किसी सर्वर और सर्वर के संसाधनों के बारे में कुछ भी जानना। मुख्य बाधा यह है कि सर्वर और क्लाइंट दोनों पर सहमत होना चाहिए मीडिया इस्तेमाल किया, जो वेब के मामले में है एचटीएमएल

एक एपीआई जो सिद्धांतों का पालन करता है आराम क्लाइंट को एपीआई की संरचना के बारे में कुछ भी जानने की आवश्यकता नहीं है। इसके बजाय, सर्वर को सेवा के साथ बातचीत करने की आवश्यकता वाले किसी भी जानकारी को प्रदान करने की आवश्यकता होती है। एक एचटीएमएल फॉर्म इसका एक उदाहरण है: सर्वर संसाधन और आवश्यक फ़ील्ड का स्थान निर्दिष्ट करता है। ब्राउजर को पहले से पता नहीं है कि जानकारी जमा करने के लिए, और यह पहले से नहीं जानता कि कौन सी जानकारी जमा करनी है। दोनों प्रकार की जानकारी सर्वर द्वारा पूरी तरह से आपूर्ति की जाती है। (इस सिद्धांत को बुलाया जाता है HATEOAS: आवेदन राज्य के इंजन के रूप में Hypermedia।)

तो, यह कैसे लागू होता है एचटीटीपी, और अभ्यास में इसे कैसे कार्यान्वित किया जा सकता है? HTTP क्रियाओं और संसाधनों के चारों ओर उन्मुख है। मुख्यधारा के उपयोग में दो क्रियाएं जीईटी और पोस्ट हैं, जो मुझे लगता है कि हर कोई पहचान लेगा। हालांकि, HTTP मानक PUT और DELETE जैसे कई अन्य लोगों को परिभाषित करता है। सर्वर द्वारा प्रदान किए गए निर्देशों के अनुसार, इन क्रियाओं को तब संसाधनों पर लागू किया जाता है।

उदाहरण के लिए, आइए कल्पना करें कि हमारे पास एक उपयोगकर्ता डेटाबेस है जो वेब सेवा द्वारा प्रबंधित किया जाता है। हमारी सेवा JSON के आधार पर एक कस्टम हाइपरमीडिया का उपयोग करती है, जिसके लिए हम mimetype असाइन करते हैं आवेदन / json + userdb (एक भी हो सकता है application / xml + userdb तथा आवेदन / जो कुछ + userdb - कई मीडिया प्रकार समर्थित हो सकते हैं)। क्लाइंट और सर्वर दोनों को इस प्रारूप को समझने के लिए प्रोग्राम किया गया है, लेकिन वे एक-दूसरे के बारे में कुछ भी नहीं जानते हैं। जैसा रॉय फील्डिंग बताता है:

एक आरईएसटी एपीआई में इसके लगभग सभी वर्णनात्मक प्रयासों को खर्च करना चाहिए   संसाधनों और ड्राइविंग का प्रतिनिधित्व करने के लिए उपयोग किए जाने वाले मीडिया प्रकार को परिभाषित करना   आवेदन स्थिति, या विस्तारित संबंध नाम और / या परिभाषित करने में   मौजूदा मानक मीडिया प्रकारों के लिए हाइपरटेक्स्ट-सक्षम मार्क-अप।

आधार संसाधन के लिए एक अनुरोध / ऐसा कुछ वापस कर सकता है:

निवेदन

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"
        }
    ]
}

हम अपने मीडिया के विवरण से जानते हैं कि हम "लिंक" नामक अनुभागों से संबंधित संसाधनों के बारे में जानकारी प्राप्त कर सकते हैं। यह कहा जाता है Hypermedia नियंत्रण। इस मामले में, हम इस तरह के एक सेक्शन से बता सकते हैं कि हम एक और अनुरोध करके उपयोगकर्ता सूची पा सकते हैं /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"
        }
    ]
}

हम इस प्रतिक्रिया से बहुत कुछ बता सकते हैं। उदाहरण के लिए, अब हम जानते हैं कि हम पोस्ट करके एक नया उपयोगकर्ता बना सकते हैं /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 इत्यादि) का उपयोग कर रहे हैं, और क्लाइंट भाग पर हम जो एकमात्र ज्ञान मानते हैं वह हमारी मीडिया परिभाषा है।

आगे की पढाई:

(यह उत्तर बिंदु को खोने के लिए आलोचना की उचित मात्रा का विषय रहा है। अधिकांश भाग के लिए, यह एक उचित आलोचना रही है। मैंने मूल रूप से वर्णित किया था कि कुछ साल पहले आरईएसटी को आम तौर पर कैसे लागू किया गया था, पहले इसे अपने वास्तविक अर्थ के बजाय लिखा था। मैंने वास्तविक अर्थ का बेहतर प्रतिनिधित्व करने के लिए उत्तर संशोधित किया है।)


2788
2018-03-22 19:37



नहीं। आरईएसटी सिर्फ एक और buzzword के रूप में पॉप अप नहीं किया था। यह SOAP- आधारित डेटा एक्सचेंज के विकल्प का वर्णन करने के साधन के रूप में आया था। आरईएसटी शब्द डेटा को स्थानांतरित करने और एक्सेस करने के बारे में चर्चा को फ्रेम करने में मदद करता है। - tvanfosson
फिर भी, आरईएसटी (व्यावहारिक अनुप्रयोग में) का दिल "परिवर्तन करने के लिए जीईटी का उपयोग न करें, POST / PUT / DELETE का उपयोग करें", जो सलाह है कि मैं सुन रहा हूं (और बाद में) SOAP प्रकट होने से बहुत पहले। आराम है हमेशा वहां रहे, इसे हाल ही में "इसे करने का तरीका" से परे एक नाम नहीं मिला। - Dave Sherohman
"आवेदन राज्य के इंजन के रूप में हाइपरटेक्स्ट" मत भूलना। - Hank Gay
यह जवाब बिंदु को याद करता है। फील्डिंग की थीसिस में HTTP का शायद ही उल्लेख किया गया है। - user359996
यह उत्तर आरईएसटी के उद्देश्य का जिक्र नहीं करता है, और ऐसा लगता है कि यह स्वच्छ यूआरआई के बारे में है। हालांकि यह आरईएसटी की लोकप्रिय धारणा हो सकती है, डी। शॉली और ओलूई के उत्तर अधिक सटीक हैं - यह आर्किटेक्चर में निर्मित सुविधाओं का लाभ लेने में सक्षम होने के बारे में है, जैसे कैशिंग, इसके बजाए इसके साथ काम करके। सुंदर यूआरआई ज्यादातर आम दुष्प्रभाव होते हैं। - T.R.


रीस्टफुल प्रोग्रामिंग के बारे में है:

  • संसाधनों को लगातार पहचानकर्ता द्वारा पहचाना जा रहा है: यूआरआई इन दिनों पहचानकर्ता की सर्वव्यापी पसंद हैं
  • संसाधनों का एक सामान्य सेट का उपयोग करके संसाधनों का उपयोग किया जा रहा है: HTTP विधियों को आम तौर पर देखा जाने वाला मामला - सम्मानजनक होता है Create, Retrieve, Update, Delete हो जाता है POST, GET, PUT, तथा DELETE। लेकिन आरईएसटी HTTP तक सीमित नहीं है, यह अभी अभी सबसे अधिक इस्तेमाल किया जाने वाला परिवहन है।
  • संसाधन के लिए पुनर्प्राप्त वास्तविक प्रतिनिधित्व अनुरोध पर निर्भर है और पहचानकर्ता नहीं है: हेडर को स्वीकार करने के लिए स्वीकार करें कि आप XML, HTTP, या यहां तक ​​कि जावा ऑब्जेक्ट को संसाधन का प्रतिनिधित्व करना चाहते हैं
  • वस्तु में राज्य को बनाए रखना और प्रतिनिधित्व में राज्य का प्रतिनिधित्व करना
  • संसाधन के प्रतिनिधित्व में संसाधनों के बीच संबंधों का प्रतिनिधित्व करना: वस्तुओं के बीच संबंध सीधे प्रतिनिधित्व में एम्बेडेड हैं
  • संसाधन प्रस्तुतिकरण वर्णन करते हैं कि प्रतिनिधित्व का उपयोग कैसे किया जा सकता है और किस परिस्थितियों में इसे निरंतर तरीके से त्याग दिया / दोहराया जाना चाहिए: HTTP कैश-कंट्रोल हेडर का उपयोग

अंतिम परिणाम शायद आरईएसटी के परिणामों और समग्र प्रभावशीलता के संदर्भ में सबसे महत्वपूर्ण है। कुल मिलाकर, अधिकांश भरोसेमंद चर्चाएं HTTP पर केंद्रित होती हैं और इसका उपयोग ब्राउज़र से होता है और क्या नहीं। मैं समझता हूं कि आर फील्डिंग ने शब्द बनाया जब उन्होंने आर्किटेक्चर और निर्णय का वर्णन किया जो HTTP की ओर ले जाते हैं। उनकी थीसिस संसाधनों की वास्तुकला और कैश-क्षमता के बारे में अधिक है जो HTTP के बारे में है।

यदि आप वास्तव में रुचि रखते हैं कि एक यथार्थ वास्तुकला क्या है और यह क्यों काम करती है, तो पढ़ें उनकी थीसिस कुछ बार और पढ़ें पूरी बात सिर्फ अध्याय 5 नहीं! आगे देखो क्यों DNS काम करता है। DNS के पदानुक्रमिक संगठन और रेफ़रल कैसे काम करते हैं, इसके बारे में पढ़ें। फिर पढ़ें और विचार करें कि कैसे DNS कैशिंग काम करता है। अंत में, HTTP विनिर्देशों को पढ़ें (RFC2616 तथा RFC3040 विशेष रूप से) और विचार करें कि कैसे और क्यों कैशिंग इस तरह से काम करता है। आखिरकार, यह सिर्फ क्लिक करेगा। मेरे लिए अंतिम प्रकाशन तब हुआ जब मैंने DNS और HTTP के बीच समानता देखी। इसके बाद, समझें कि एसओए और संदेश पासिंग इंटरफेस स्केलेबल क्यों क्लिक करना शुरू कर देते हैं।

मुझे लगता है कि एक यथार्थवादी महत्व और प्रदर्शन के प्रभाव को समझने के लिए सबसे महत्वपूर्ण चाल है कुछ भी साझा नहीं किया गया आर्किटेक्चर प्रौद्योगिकी और कार्यान्वयन के विवरण पर लटका पाने से बचने के लिए है। संसाधनों का मालिक कौन है, इस पर ध्यान केंद्रित करें, जो उन्हें बनाने / बनाए रखने के लिए ज़िम्मेदार है, आदि। फिर प्रस्तुतिकरण, प्रोटोकॉल और प्रौद्योगिकियों के बारे में सोचें।


500
2017-07-04 05:47



एक पठन सूची प्रदान करने वाला एक उत्तर इस प्रश्न के लिए बहुत उपयुक्त है। - ellisbben
अद्यतन के लिए धन्यवाद। PUT तथा POST अद्यतन और बनाने के साथ वास्तव में एक-दूसरे को मानचित्र न करें। PUT यह बनाने के लिए इस्तेमाल किया जा सकता है कि क्लाइंट यह बता रहा है कि यूआरआई क्या होगा। POST बनाता है अगर सर्वर नई यूआरआई असाइन कर रहा है। - D.Shawley
पैच मत भूलना। - epitka
एक यूआरएन एक यूआरआई है जो इसका उपयोग करता है urn: योजना। संकल्पनात्मक रूप से कोई अंतर नहीं है; हालांकि, एक यूआरएन की आवश्यकता है कि आपके पास यूआरएन द्वारा पहचाने जाने वाले संसाधन (नामित) "को ढूंढने" के लिए एक अलग परिभाषित विधि है। यह सुनिश्चित करने के लिए सावधानी बरतनी चाहिए कि आप नामित संसाधनों और उनके स्थान से संबंधित होने पर अंतर्निहित युग्मन शुरू नहीं करते हैं। - D.Shawley
@ellisbben सहमत अगर मैं सही ढंग से समझता हूं तो यह शोध प्रबंध है जो आरईएसटी को जन्म देता है: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm - Philip Couling


यह वही दिख सकता है।

तीन गुणों वाला उपयोगकर्ता बनाएं:

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 शून्य होगा):

PUT /user/123
fname=Johnny

392
2017-11-18 20:46



मेरे लिए इस जवाब ने वांछित उत्तर के सार पर कब्जा कर लिया। सरल और व्यावहारिक। माना जाता है कि कई अन्य मानदंड हैं, लेकिन प्रदान किया गया उदाहरण एक महान लॉन्च पैड है। - CyberFonic
आखिरी उदाहरण में, @pbreitenbach उपयोग करता है PUT fname=Jonny। यह सेट होगा lname तथा age डिफ़ॉल्ट मानों (संभवतः पूर्ण या खाली स्ट्रिंग, और पूर्णांक 0) के लिए, क्योंकि ए PUT  पूरे संसाधन को ओवरराइट करता है प्रदान किए गए प्रतिनिधित्व से डेटा के साथ। यह "अद्यतन" द्वारा निहित नहीं है, एक असली अद्यतन करने के लिए, का उपयोग करें PATCH तरीका क्योंकि यह उन फ़ील्ड को परिवर्तित नहीं करता है जो प्रतिनिधित्व में निर्दिष्ट नहीं हैं। - Nicholas Shanks
निकोलस सही है। इसके अलावा, उपयोगकर्ता को बनाने वाले पहले पोस्ट के लिए यूआरआई उपयोगकर्ताओं को कहा जाना चाहिए क्योंकि /user/1 कोई समझ नहीं आता है और वहां एक लिस्टिंग होनी चाहिए /users। प्रतिक्रिया एक होना चाहिए 201 Created और उस मामले में ठीक नहीं है। - DanMan
निकोलस और दानमन सही हैं। यह उत्तर संक्षेप में है लेकिन इसमें कई त्रुटियां हैं। - leslie.zhang
यह सिर्फ एक एपीआई का एक उदाहरण है जो एक आवश्यक एपीआई नहीं है। एक भरोसेमंद में बाधाएं होती हैं जो इसका पालन करती है। क्लाइंट-सर्वर आर्किटेक्चर, स्टेटलेस, कैश-क्षमता, स्तरित सिस्टम, वर्दी इंटरफ़ेस। - Radmation


आरईएसटी पर एक महान किताब है अभ्यास में आरईएसटी

पढ़ना चाहिए प्रतिनिधि राज्य स्थानांतरण (आरईएसटी) तथा आरईएसटी एपीआई हाइपरटेक्स्ट-संचालित होना चाहिए 

मार्टिन फाउलर्स लेख देखें रिचर्डसन परिपक्वता मॉडल (आरएमएम) एक भरोसेमंद सेवा के बारे में एक स्पष्टीकरण के लिए।

Richardson Maturity Model

एक सेवा को पूरा करने की जरूरत है आवेदन राज्य के इंजन के रूप में Hypermedia। (HATEOAS), यानी, इसे आरएमएम में स्तर 3 तक पहुंचने की जरूरत है, यह पढ़ो विवरण के लिए या क्यूकन टॉक से स्लाइड

HATEOAS बाधा एक संक्षिप्त शब्द है   इंजन के रूप में Hypermedia के लिए   आवेदन राज्य यह सिद्धांत है   एक आरईएसटी के बीच महत्वपूर्ण अंतर   और क्लाइंट सर्वर के अधिकांश अन्य रूपों   प्रणाली।

...

एक भरोसेमंद आवेदन के एक ग्राहक की जरूरत है   केवल पहुंच के लिए एक निश्चित यूआरएल पता है   यह। सभी भविष्य की कार्रवाई होनी चाहिए   से गतिशील रूप से खोजने योग्य   hypermedia लिंक में शामिल हैं   संसाधनों के प्रतिनिधित्व   उस यूआरएल से वापस आ गए हैं।   मानकीकृत मीडिया प्रकार भी हैं   किसी भी द्वारा समझा जाने की उम्मीद है   क्लाइंट जो एक विश्वसनीय API का उपयोग कर सकता है।   (विकिपीडिया, मुक्त विश्वकोश से)

वेब फ्रेमवर्क के लिए आरईएसटी लिटमस टेस्ट वेब ढांचे के लिए एक समान परिपक्वता परीक्षण है।

शुद्ध REST के पास: HATEOAS प्यार करने के लिए सीखना लिंक का एक अच्छा संग्रह है।

सार्वजनिक बादल के लिए एसओएपी बनाम आरईएसटी आरईएसटी उपयोग के मौजूदा स्तर पर चर्चा करता है।

आरईएसटी और संस्करण विस्तारशीलता, संस्करण, उत्थान, आदि पर चर्चा  संशोधितता के माध्यम से


170
2018-03-22 15:20



मुझे लगता है कि यह उत्तर REST समझने के मुख्य बिंदु को छूता है: शब्द क्या है प्रतिनिधित्ववादी मतलब है। स्तर 1 - संसाधनों के बारे में कहते हैं राज्य। स्तर 2 - HTTP Verbs के बारे में कहते हैं स्थानांतरण (पढ़ परिवर्तन)। स्तर 3 - हेटोएस का कहना है कि प्रतिनिधित्व के माध्यम से भविष्य हस्तांतरण (जेएसओएन / एक्सएमएल / एचटीएमएल लौटा), जिसका मतलब है कि आपको पता चला है कि वापस आने वाली जानकारी के साथ अगले दौर के बारे में बात कैसे करें। तो आरईएसटी पढ़ता है: "(प्रतिनिधित्व (राज्य हस्तांतरण))" के बजाय "((प्रतिनिधित्वकारी राज्य) हस्तांतरण)"। - lcn
आरईएसटी और पीओएक्स के बीच अंतर - nobar


आरईएसटी क्या है?

आरईएसटी प्रतिनिधि राज्य हस्तांतरण के लिए खड़ा है। (यह कभी-कभी होता है   वर्तनी "आरईएसटी"।) यह एक स्टेटलेस, क्लाइंट-सर्वर, कैशेबल पर निर्भर करता है   संचार प्रोटोकॉल - और लगभग सभी मामलों में, HTTP   प्रोटोकॉल का उपयोग किया जाता है।

आरईएसटी नेटवर्किंग अनुप्रयोगों को डिजाइन करने के लिए एक वास्तुकला शैली है।   विचार यह है कि, कॉरबा जैसे जटिल तंत्र का उपयोग करने के बजाय,   मशीनों के बीच कनेक्ट करने के लिए आरपीसी या एसओएपी, सरल HTTP बनाने के लिए प्रयोग किया जाता है   मशीनों के बीच कॉल

कई मायनों में, HTTP वाइड वेब, HTTP पर आधारित है, को देखा जा सकता है   एक आरईएसटी आधारित वास्तुकला के रूप में। विश्वसनीय अनुप्रयोग HTTP अनुरोध का उपयोग करते हैं   डेटा पोस्ट करने के लिए (बनाएं और / या अपडेट करें), डेटा पढ़ें (उदा।, प्रश्न पूछें)   और डेटा हटाएं। इस प्रकार, आरईएसटी सभी चार सीआरयूडी के लिए HTTP का उपयोग करता है   (बनाएँ / पढ़ें / अपडेट / हटाएं) संचालन।

आरईएसटी आरपीसी (रिमोट) जैसे तंत्र के लिए हल्का विकल्प है   प्रक्रिया कॉल) और वेब सेवाएं (एसओएपी, डब्ल्यूएसडीएल, एट अल।)। बाद में, हम करेंगे   देखें कि आरईएसटी कितना आसान है।

सरल होने के बावजूद, आरईएसटी पूरी तरह से फीचर्ड है; मूल रूप से है   कुछ भी नहीं जो आप वेब सेवाओं में कर सकते हैं जिसे एक रेस्टस्टुल के साथ नहीं किया जा सकता है   आर्किटेक्चर। आरईएसटी एक "मानक" नहीं है। कभी डब्लू 3 सी नहीं होगा   उदाहरण के लिए, आरईएसटी के लिए सिफारिश। और जबकि आरईएसटी हैं   प्रोग्रामिंग ढांचे, आरईएसटी के साथ काम करना इतना आसान है कि आप कर सकते हैं   भाषाओं में मानक लाइब्रेरी सुविधाओं के साथ अक्सर "अपना खुद का रोल करें"   पर्ल, जावा, या सी #।

जब मैं आराम के सरल वास्तविक अर्थ को खोजने का प्रयास करता हूं तो मुझे सबसे अच्छा संदर्भ मिला।

http://rest.elkstein.org/


128
2018-03-22 14:53





आरईएसटी डेटा को कुशल बनाने के लिए विभिन्न HTTP विधियों (मुख्य रूप से GET / PUT / DELETE) का उपयोग कर रहा है।

एक विधि को हटाने के लिए एक विशिष्ट यूआरएल का उपयोग करने के बजाय (कहें, /user/123/delete), आप एक डेली अनुरोध भेज देंगे /user/[id] यूआरएल, उपयोगकर्ता को संपादित करने के लिए, उस उपयोगकर्ता को जानकारी प्राप्त करने के लिए जिसे आप एक GET अनुरोध भेजते हैं /user/[id]

उदाहरण के लिए, इसके बजाय यूआरएल का एक सेट जो निम्न में से कुछ जैसा दिख सकता है ..

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

85
2017-07-12 16:33



यह "HTTP का सही उपयोग कर रहा है", जो "restful" जैसा नहीं है (हालांकि यह इससे संबंधित है) - Julian Reschke
आप / user / del / 2 और / user / remove / 2 या ... GET / DELETE / PUT / POST भी ऐसी चीजों को करने के लिए मानकीकृत, "उचित" तरीका उपयोग कर सकते हैं (और जूलियन कहते हैं, यह सब नहीं है आरईएसटी है) - dbr
निश्चित रूप से, लेकिन उनसे बचने का कोई कारण नहीं है .. REST बस आपको हर बार पहिया को फिर से शुरू करने से बचाता है। एक एपीआई के लिए, आरईएसटी महान (स्थिरता!) है, लेकिन एक यादृच्छिक वेबसाइट की संरचना के लिए यह वास्तव में कोई फर्क नहीं पड़ता कि मैं कहूंगा (यह इसके लायक से अधिक परेशानी हो सकती है) - dbr
वादिम, यह बस आरपीसी होगा। डेटा को संशोधित करने के लिए जीईटी का उपयोग करना भी खतरनाक है (अन्य कारणों से) एक खोज इंजन आपके विलोपन लिंक को मकड़ी दे सकता है और उन सभी पर जा सकता है। - aehlke
@ एहलेके - मुझे लगता है कि वास्तविक सवाल यह होगा कि "अज्ञात उपयोगकर्ता के पास आपके सिस्टम से रिकॉर्ड हटाने की क्षमता क्यों है?" - Spencer Ruport


यह प्रोग्रामिंग है जहां आपके सिस्टम की वास्तुकला फिट बैठती है आरईएसटी शैली रॉय फील्डिंग द्वारा रखी गई उनकी थीसिस। चूंकि यह वास्तुशिल्प शैली है जो वेब (अधिक या कम) का वर्णन करती है, इसलिए बहुत से लोग इसमें रूचि रखते हैं।

बोनस उत्तर: नहीं। जब तक आप एक अकादमिक या डिजाइनिंग वेब सेवाओं के रूप में सॉफ़्टवेयर आर्किटेक्चर का अध्ययन नहीं कर रहे हैं, तो शब्द को सुनने के लिए वास्तव में कोई कारण नहीं है।


64
2018-03-23 17:11



लेकिन सीधे आगे नहीं .. यह और अधिक जटिल बनाता है कि यह होना चाहिए। - hasen
इसके अलावा, भले ही आरईएसटी और रीस्टफुल शब्द पूरी तरह से वेब अनुप्रयोगों के दायरे में लगभग विशेष रूप से उपयोग किए जाते हैं, तकनीकी रूप से HTTP में रीस्ट टाइपिंग कुछ भी नहीं है। - Hank Gay
फील्डिंग के ब्लॉग में आरईएसटी और सामान्य गलतफहमी पर लेखों को समझना कुछ अच्छा, आसान है: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven - aehlke
@ हैंकगे मुझे लगता है कि यह अधिक गूढ़ नहीं है क्योंकि अधिकांश वेब सेवा डेवलपर्स एसईएपी जैसे विकल्पों पर एक अद्भुत सरलीकरण के रूप में आरईएसटी देखते हैं। वे सभी रीस्ट टेक्नोलॉजीज को सही करने के लिए जरूरी नहीं हैं - और संभवत: आरईएसटी कट्टरपंथियों को पागल कर देते हैं - लेकिन ज्यादातर मामलों में उन्हें शायद यह सुनिश्चित करने की ज़रूरत नहीं है कि उनके परिणाम "हाइपर्मियाडिया-सक्षम" हैं। - moodboom