वास्तव में RESTful प्रोग्रामिंग क्या है?


3983

वास्तव में RESTful प्रोग्रामिंग क्या है?


3
नीचे दिए गए लिंक stackoverflow.com/a/37683965/3762855
Ciro Corvino

3
REST अब थोड़ा पुराना हो सकता है;) youtu.be/WQLzZf34FJ8
व्लादि वेसलिनोव

1
इसके अलावा, कुछ और जानकारी के लिए इस लिंक को देखें 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/web0116005443/http://tomayko है। com / लेखन /…
kushalvm

5
@ OLIVER.KOO अच्छा अवलोकन। यह सिर्फ इतना है कि मैंने इसे ऐसे समय में पूछा जब यह एक नई चीज की तरह था। इसे बहुत फेंका जा रहा था लेकिन बहुत से लोग नहीं जानते थे कि यह क्या है। कम से कम मैंने नहीं किया, और ऐसा लगता है कि मुझे यह पूछने में मदद मिली है क्योंकि उन्होंने भी जानना चाहा है।
hasen

जवाबों:


743

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

अन्य प्रस्तोता 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 फ़ेस बुक से ली गई है।


2
उपलब्ध अनुपलब्ध संचालन: जीईटी (सुरक्षित), PUT & DELETE (अपवाद इस लिंक restapitutorial.com/lessons/idempotency.html) में उल्लेख किया गया है। अतिरिक्त और सुरक्षित तरीके के लिए संदर्भ W3.org/Protocols/rfc2616/rfc2616-sec9.html
Abhijeet

5
ए) जीईटी के बारे में महत्वपूर्ण बिंदु सुरक्षितता है, न कि बेरोजगारी, बी) @ अभिजीत: आरएफसी 2616 को 2014 में बाधित किया गया है; आरएफ 7230ff देखें।
जूलियन रिस्के

12
ये गलत है। बाकी की सही व्याख्या के लिए इस पढ़ें roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven या इस stackoverflow.com/questions/19843480/...
kushalvm

4
@kushalvm REST की शैक्षणिक परिभाषा का उपयोग व्यवहार में नहीं किया जाता है।
वारिम्प चिंपाजी

3
प्रभावी रूप से हम आश्चर्यचकित कर सकते हैं कि यदि कोई अवधारणा चालू है, क्योंकि हम इसे सरल करने में विफल रहते हैं, तो सभी के लिए एक स्थिर और समझने योग्य परिभाषा है
HoCo_

2918

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 लागू किया गया था, तब तक कैसे था। पहले अपने वास्तविक अर्थ के बजाय यह लिखा है। मैंने वास्तविक अर्थ को बेहतर ढंग से प्रस्तुत करने के लिए उत्तर को संशोधित किया है।)


178
नहीं बस एक और चर्चा के रूप में पॉप अप नहीं किया। यह SOAP- आधारित डेटा विनिमय के लिए एक विकल्प का वर्णन करने के साधन के रूप में आया था। REST शब्द डेटा को स्थानांतरित करने और एक्सेस करने के तरीके के बारे में चर्चा को फ्रेम करने में मदद करता है।
tvanfosson

111
बहरहाल, REST का दिल (व्यावहारिक अनुप्रयोग में) "बदलाव करने के लिए GET का उपयोग न करें, POST / PUT / DELETE का उपयोग करें", जो कि सलाह है कि मैं SOAP दिखाई देने से बहुत पहले से (और बाद में) सुन रहा हूं। बाकी है हमेशा वहाँ गया है, यह सिर्फ एक नाम से परे "जिस तरह से यह करने के लिए" हाल ही में जब तक मिला।
डेव शेरोहमान

37
"आवेदन राज्य के इंजन के रूप में हाइपरटेक्स्ट" मत भूलना।
हांक गे

45
यह उत्तर बात याद आती है। फील्डिंग की थीसिस में HTTP का उल्लेख मुश्किल से होता है।
user359996

18
इस उत्तर में REST के उद्देश्य का उल्लेख नहीं है, और ऐसा लगता है कि यह सभी स्वच्छ URI के बारे में है। हालांकि यह REST की लोकप्रिय धारणा हो सकती है, D.Shawley's और oluies के उत्तर अधिक सटीक हैं - यह आर्किटेक्चर में निर्मित सुविधाओं का लाभ उठाने में सक्षम है, कैशिंग की तरह, इसके खिलाफ काम करने के बजाय इसके साथ काम करके। प्रीटियर यूआरआई ज्यादातर एक आम दुष्प्रभाव हैं।
TR

534

RESTful प्रोग्रामिंग के बारे में है:

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

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

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

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


36
इस प्रश्न के लिए एक पठन सूची प्रदान करने वाला उत्तर बहुत उपयुक्त है।
दीर्घवृत्त

25
अद्यतन के लिए धन्यवाद। PUTऔर POSTवास्तव में अपडेट और क्रिएट के साथ वन-टू-वन मैप न करें। PUTयह बनाने के लिए इस्तेमाल किया जा सकता है कि क्या ग्राहक यूआरआई होगा जो तय कर रहा है। POSTसर्वर नया URI असाइन कर रहा है, तो बनाता है।
23

8
पाथ मत भूलना।
इप्टा

4
एक यूआरएन एक यूआरआई है जो urn:योजना का उपयोग करता है । वैचारिक रूप से कोई अंतर नहीं है; हालांकि, एक URN की आवश्यकता है कि आपके पास URN द्वारा पहचाने गए (नामित) संसाधन का "पता लगाने" के लिए एक अलग से परिभाषित विधि है। यह सुनिश्चित करने के लिए ध्यान रखा जाना चाहिए कि आप नामित संसाधनों और उनके स्थान से संबंधित निहित युग्मन का परिचय न दें।
डी। शेवले

2
@ellisbben सहमत हैं। अगर मैं सही ढंग से
समझूं तो

408

यह ऐसा हो सकता है जैसा दिखता है।

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

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और ageNULL होगा):

PUT /user/123
fname=Johnny

39
मेरे लिए इस उत्तर ने वांछित उत्तर का सार पकड़ लिया। सरल और व्यावहारिक। दी गई कई अन्य मापदंड हैं, लेकिन प्रदान किया गया उदाहरण एक महान लॉन्च पैड है।
साइबर फॉन

92
अंतिम उदाहरण में, @pbreitenbach का उपयोग करता है PUT fname=Jonny। यह मानों को डिफ़ॉल्ट रूप से सेट करेगा lnameऔर age(शायद NULL या खाली स्ट्रिंग, और पूर्णांक 0), क्योंकि प्रदत्त प्रतिनिधित्व से डेटा के साथ PUT पूरे संसाधन को ओवरराइट करता है । यह वह नहीं है जो "अपडेट" द्वारा निहित है, वास्तविक अपडेट करने के लिए, PATCHविधि का उपयोग करें क्योंकि यह उन फ़ील्ड को नहीं बदलता है जो प्रतिनिधित्व में निर्दिष्ट नहीं हैं।
निकोलस शैंक्स

24
निकोलस सही है। इसके अलावा, उपयोगकर्ता बनाने वाले पहले POST के लिए URI को उपयोगकर्ता कहा जाना चाहिए क्योंकि इसका /user/1कोई मतलब नहीं है और इसमें एक सूची होनी चाहिए /users। प्रतिक्रिया एक होनी चाहिए 201 Createdऔर केवल उस मामले में ठीक नहीं होनी चाहिए ।
डैनमैन

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

यह एक बहुत ही कॉम्पैक्ट उत्तर है जो सभी http सर्वलेट एक्सेस के तरीकों को कवर करता है
हिमांशु आहूजा

181

REST पर एक महान पुस्तक है REST प्रैक्टिस में

रीड्स रिप्रेजेंटेटिव स्टेट ट्रांसफर (REST) ​​हैं और REST API को हाइपरटेक्स्ट-चालित होना चाहिए

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

रिचर्डसन परिपक्वता मॉडल

रेस्टफुल होने के लिए एक सेवा को अनुप्रयोग राज्य के इंजन के रूप में हाइपरमीडिया को पूरा करना होगा (HATEOAS) , अर्थात, इसे RMM में स्तर 3 तक पहुंचने की जरूरत है, विवरण के लिए लेख पढ़ें या क्यूक टॉक से स्लाइड

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

...

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

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

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

सार्वजनिक क्लाउड के लिए REST बनाम SOAP, REST उपयोग के वर्तमान स्तरों पर चर्चा करता है।

REST और संस्करणकरण में परिवर्तनशीलता के माध्यम से एक्स्टेंसिबिलिटी, वर्जनिंग , Evolvability, आदि की चर्चा होती है


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


136

REST क्या है?

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

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

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

REST, RPC (दूरस्थ प्रक्रिया कॉल) और वेब सेवा (SOAP, WSDD, एट अल।) जैसे तंत्र का एक हल्का विकल्प है। बाद में, हम देखेंगे कि REST कितना सरल है।

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

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

http://rest.elkstein.org/


यह वास्तव में संक्षिप्त जवाब है। क्या आप यह भी बता सकते हैं कि REST को स्टेटलेस क्यों कहा जाता है?
चाकलादेर असफाक

89

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

18
यह "HTTP का ठीक से उपयोग करना" है, जो "रेस्टफुल" के समान नहीं है (हालाँकि यह इससे संबंधित है)
जूलियन रेसके ने

2
आप / user / del / 2 और / user / remove / 2 या ... GET / DELETE / PUT / POST का उपयोग कर सकते हैं, बस इस तरह की चीजों को करने के लिए मानकीकृत, "उचित" तरीका है (और जैसा कि जूलियन कहते हैं, यह सब नहीं है वहाँ है)
21

1
ज़रूर, लेकिन उनसे बचने का कोई कारण नहीं है .. बस आपको हर बार पहिया को फिर से लगाने से बचाता है। एक एपीआई के लिए, REST महान है (संगतता!), लेकिन एक यादृच्छिक वेबसाइट को संरचित करने के लिए यह वास्तव में मायने नहीं रखता है (मैं इसके लायक होने से अधिक परेशानी हो सकती है)
dbr

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

7
@aehlke - मुझे लगता है कि असली सवाल यह होगा कि "अनाम उपयोगकर्ता में आपके सिस्टम से रिकॉर्ड हटाने की क्षमता क्यों होती है?"
स्पेंसर रूपर्ट

68

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

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


2
लेकिन सीधे-आगे नहीं .. इसे और अधिक जटिल बनाता है कि इसे होने की आवश्यकता है।
hasen

4
इसके अलावा, भले ही REST और RESTful का उपयोग अभी वेब अनुप्रयोगों के दायरे में लगभग विशेष रूप से किया जाता है, लेकिन तकनीकी रूप से HTTP पर REST को बांधने में कुछ भी नहीं है।
हांक गे

3
: क्षेत्ररक्षण के ब्लॉग कुछ अच्छा है, आसान बाकी पर समझ लेख और आम गलतफहमी गया है roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
aehlke

3
@HankGay मुझे लगता है कि यह कारण अधिक गूढ़ नहीं है कि ज्यादातर वेब सेवा डेवलपर्स REST को SOAP जैसे विकल्पों पर एक अद्भुत सरलीकरण के रूप में देखते हैं। वे जरूरी नहीं कि सभी REST तकनीकी को सही करने के लिए चिपके रहते हैं - और यह शायद REST कट्टरपंथियों को पागल बना देता है - लेकिन ज्यादातर मामलों में उन्हें शायद इस बात की चिंता करने की ज़रूरत नहीं है कि उनके परिणाम "हाइपरमीडिया-सक्षम" हैं।
मूडबूम

47

मैं कहूंगा कि RESTful प्रोग्रामिंग सिस्टम (API) बनाने के बारे में होगी जो REST आर्किटेक्चरल स्टाइल को फॉलो करती है।

मैंने डॉ। एम। एल्कस्टीन द्वारा रीस्ट के बारे में इस शानदार, लघु और आसान को समझना आसान समझा और उस आवश्यक भाग को उद्धृत किया जो आपके प्रश्न का सबसे अधिक भाग के लिए उत्तर देगा:

बाकी जानें: एक ट्यूटोरियल

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

  • कई मायनों में, HTTP पर आधारित वर्ल्ड वाइड वेब को REST- आधारित वास्तुकला के रूप में देखा जा सकता है।

ईमानदार एप्लिकेशन डेटा (पोस्ट और / या अपडेट), डेटा पढ़ने (उदाहरण के लिए, प्रश्न बनाने) और डेटा को हटाने के लिए HTTP अनुरोधों का उपयोग करते हैं। इस प्रकार, REST सभी चार CRUD (क्रिएट / रीड / अपडेट / डिलीट) ऑपरेशंस के लिए HTTP का उपयोग करता है।

मुझे नहीं लगता कि स्टैक ओवरफ्लो के बाहर REST के बारे में न सुनने के लिए आपको बेवकूफ महसूस करना चाहिए ..., मैं उसी स्थिति में रहूंगा ;; इस सवाल पर अन्य एसओ का जवाब क्यों आरईएसटी बड़ा हो रहा है अब कुछ भावनाओं को कम कर सकता है।


यह लेख HTTP और REST के बीच के रिश्ते को बताता है freecodecamp.org/news/…
केवल आप

45

अगर मैं सीधे सवाल का जवाब नहीं दे रहा हूं, तो मैं माफी चाहता हूं, लेकिन अधिक विस्तृत उदाहरणों के साथ यह सब समझना आसान है। तमाम अमूर्तता और शब्दावली के कारण फील्डिंग को समझना आसान नहीं है।

यहाँ एक अच्छा उदाहरण है:

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 है।)


12
शांत लिंक, धन्यवाद। मैं इन REST लोगों से थक गया हूँ जो कहते हैं कि कुछ उदाहरण "REST-ful" नहीं है, लेकिन फिर यह कहने से इंकार कर दिया कि REST-ful होने के लिए उदाहरण को कैसे बदला जाए।
कोडर_टीम

38

REST क्या है?

आधिकारिक शब्दों में, आरईएसटी एक वास्तुशिल्प शैली है जिसे वर्तमान "वेब" मूल सिद्धांतों का उपयोग करके कुछ सिद्धांतों पर बनाया गया है। वेब के 5 मूल फंडामेंटल हैं जो आरईएसटी सेवाओं को बनाने के लिए उपयोग किए जाते हैं।

  • सिद्धांत 1: सब कुछ एक संसाधन है REST वास्तु शैली में, डेटा और कार्यक्षमता को संसाधन माना जाता है और यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI) का उपयोग करके एक्सेस किया जाता है, आमतौर पर वेब पर लिंक।
  • सिद्धांत 2: प्रत्येक संसाधन की पहचान एक विशिष्ट पहचानकर्ता (URI) द्वारा की जाती है
  • सिद्धांत 3: सरल और समान इंटरफेस का उपयोग करें
  • सिद्धांत ४: संचार प्रतिनिधित्व द्वारा किया जाता है
  • सिद्धांत 5: स्टेटलेस बनें

1
क्या Communication is Done by Representationमतलब है?
मेंडेज़ 7

33

मुझे उत्तरों का एक गुच्छा दिखाई देता है जो कहते हैं कि संसाधन 123 पर उपयोगकर्ता के बारे में सब कुछ डालना "/ उपयोगकर्ता / 123" RESTful है।

रॉय फील्डिंग, जिन्होंने इस शब्द को गढ़ा था, कहते हैं कि REST API को हाइपरटेक्स्ट-चालित होना चाहिए । विशेष रूप से, "A REST API को निश्चित संसाधन नामों या पदानुक्रमों को परिभाषित नहीं करना चाहिए"।

इसलिए यदि आपका "/ user / 123" पथ क्लाइंट पर हार्डकोड किया गया है, तो यह वास्तव में Restful नहीं है। HTTP का एक अच्छा उपयोग, हो सकता है, शायद नहीं। लेकिन रेस्टफुल नहीं। यह हाइपरटेक्स्ट से आना है।


7
इसलिए .... वह उदाहरण कैसे होगा? आप इसे बदलने के लिए url को कैसे बदलेंगे?
hasen

1
hasen: Restfulness के लिए सभी कार्यों के लिए एक संसाधन का उपयोग करना आवश्यक हो सकता है , लेकिन यह पर्याप्त नहीं है ।
केन

18
ठीक है .. क्या आप आगे बता सकते हैं? यह कहने का क्या मतलब है "ये लोग गलत नहीं हैं .. मुझे पता है कि क्या सही है" बिना यह कहे कि आप क्या जानते हैं (या सोचते हैं) सही होना?
hasen

5
मैंने फील्डिंग के विवरण का लिंक दिया। मुझे लगा कि मैंने कहा कि वास्तव में प्रासंगिक अन्य प्रतिक्रियाओं के लिए अलग है: हाइपरटेक्स्ट द्वारा संचालित करने की आवश्यकता है। यदि "/ user / 123" कुछ आउट-ऑफ-बैंड एपीआई प्रलेखन से आता है, तो यह रेस्टफुल नहीं है। यदि यह आपके हाइपरटेक्स्ट में संसाधन पहचानकर्ता से आता है, तो यह है।
केन

1
या आप / उपयोगकर्ता / जैसे एक प्रवेश बिंदु का उपयोग कर सकते हैं और यह आपको प्रत्येक के लिए उपयोगकर्ता संसाधनों और यूआरआई की एक सूची देगा। तब संसाधन खोज योग्य होते हैं और नेविगेशन हाइपरटेक्स्ट-चालित होता है।
ऐहलके

26

इसका उत्तर बहुत सरल है, रॉय फील्डिंग द्वारा लिखा गया एक शोध प्रबंध है।] 1 इस शोध प्रबंध में उन्होंने REST सिद्धांतों को परिभाषित किया है। यदि कोई एप्लिकेशन उन सभी सिद्धांतों को पूरा करता है, तो यह एक REST एप्लीकेशन है।

RESTful शब्द इसलिए बनाया गया था क्योंकि ppl ने REST शब्द को उनके गैर- REST अनुप्रयोग को REST के रूप में समाप्त कर दिया था। उसके बाद Restful शब्द समाप्त हो गया था। आजकल हम Web API और Hypermedia API के बारे में बात कर रहे हैं , क्योंकि तथाकथित REST अनुप्रयोगों में से अधिकांश ने समान इंटरफ़ेस बाधा के HATEOAS भाग को पूरा नहीं किया है।

बाकी बाधाएँ निम्नलिखित हैं:

  1. क्लाइंट-सर्वर आर्किटेक्चर

    इसलिए यह PUB / SUB सॉकेट के उदाहरण के साथ काम नहीं करता है, यह REQ / REP पर आधारित है।

  2. स्टेटलेस संचार

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

  3. कैश का उपयोग यदि आप कर सकते हैं

    इसलिए आपको बार-बार समान अनुरोधों की सेवा करने की आवश्यकता नहीं है।

  4. क्लाइंट और सर्वर के बीच समान अनुबंध के रूप में समान इंटरफ़ेस

    क्लाइंट और सर्वर के बीच अनुबंध सर्वर द्वारा बनाए नहीं रखा जाता है। दूसरे शब्दों में ग्राहक को सेवा के कार्यान्वयन से अलग किया जाना चाहिए। आप मानक समाधानों का उपयोग करके इस राज्य तक पहुंच सकते हैं, जैसे संसाधनों की पहचान करने के लिए आईआरआई (यूआरआई) मानक, संदेशों का आदान-प्रदान करने के लिए 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 वोकैब के साथ, उदाहरण के लिए हाइड्रा वोकैब के और डोमेन विशिष्ट स्वर जैसेस्कीमा.ऑर्ग या किसी अन्य लिंक किए गए डेटा वोकैब और यदि आवश्यक हो तो एक कस्टम एप्लिकेशन विशिष्ट वोकैब। अब यह आसान नहीं है, यही कारण है कि अधिकांश पीपीएल एचएएल और अन्य सरल प्रारूपों का उपयोग करते हैं जो आमतौर पर केवल आरईएसटी वोकैब प्रदान करते हैं, लेकिन कोई डेटा समर्थन नहीं।

  5. स्केलेबिलिटी बढ़ाने के लिए एक स्तरित प्रणाली का निर्माण

    आरईएसटी सिस्टम पदानुक्रमित परतों से बना है। प्रत्येक परत में घटक होते हैं जो घटकों की सेवाओं का उपयोग करते हैं जो नीचे की अगली परत में होते हैं। तो आप आसानी से नई परतों और घटकों को जोड़ सकते हैं।

    उदाहरण के लिए एक क्लाइंट लेयर होती है जिसमें क्लाइंट होते हैं और उसके नीचे एक सर्विस लेयर होती है जिसमें सिंगल सर्विस होती है। अब आप उनके बीच क्लाइंट साइड कैश जोड़ सकते हैं। उसके बाद आप एक और सेवा उदाहरण और एक लोड बैलेंसर जोड़ सकते हैं, और इसी तरह ... ग्राहक कोड और सेवा कोड नहीं बदलेगा।

  6. ग्राहक की कार्यक्षमता का विस्तार करने की मांग पर कोड

    यह बाधा वैकल्पिक है। उदाहरण के लिए, आप क्लाइंट के लिए एक विशिष्ट मीडिया प्रकार के लिए एक पार्सर भेज सकते हैं, और इसी तरह ... ऐसा करने के लिए आपको क्लाइंट में एक मानक प्लगइन लोडर प्रणाली की आवश्यकता हो सकती है, या आपका क्लाइंट प्लगइन लोडर समाधान के लिए युग्मित होगा। ।

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


22

Restful (प्रतिनिधि राज्य हस्तांतरण) API प्रोग्रामिंग किसी भी प्रोग्रामिंग भाषा में 5 मूल सॉफ्टवेयर आर्किटेक्चर शैली सिद्धांतों का पालन ​​करके वेब एप्लिकेशन लिख रहा है :

  1. संसाधन (डेटा, सूचना)।
  2. अद्वितीय वैश्विक पहचानकर्ता (सभी संसाधन यूआरआई द्वारा विशिष्ट पहचान किए जाते हैं )।
  3. यूनिफ़ॉर्म इंटरफ़ेस - सरल और मानक इंटरफ़ेस (HTTP) का उपयोग करें।
  4. प्रतिनिधित्व - सभी संचार प्रतिनिधित्व द्वारा किया जाता है (जैसे XML / JSON )
  5. स्टेटलेस (प्रत्येक अनुरोध पूर्ण अलगाव में होता है, यह कैश और लोड-बैलेंस के लिए आसान है),

दूसरे शब्दों में, आप HTTP पर सरल पॉइंट-टू-पॉइंट नेटवर्क एप्लिकेशन लिख रहे हैं, जो GEST, POST, PUT या DELETE जैसी क्रियाओं का उपयोग करके Restful आर्किटेक्चर को लागू करते हैं जो प्रत्येक "संसाधन" इंटरफ़ेस के मानकीकरण का प्रस्ताव रखता है। यह कुछ भी नहीं है कि एक सरल और प्रभावी तरीके से वेब की वर्तमान विशेषताओं का उपयोग करना (अत्यधिक सफल, सिद्ध और वितरित वास्तुकला)। यह SOAP , CORBA और RPC जैसे अधिक जटिल तंत्रों का एक विकल्प है ।

रीस्टफुल प्रोग्रामिंग वेब आर्किटेक्चर डिजाइन के अनुरूप है और यदि इसे ठीक से लागू किया जाता है, तो यह आपको स्केलेबल वेब इन्फ्रास्ट्रक्चर का पूरा लाभ उठाने की अनुमति देता है।


17

अगर मुझे REST पर मूल शोध प्रबंध को केवल 3 छोटे वाक्यों को कम करना था, तो मुझे लगता है कि निम्नलिखित इसके सार को कैप्चर करता है:

  1. URL के माध्यम से संसाधनों का अनुरोध किया जाता है।
  2. प्रोटोकॉल सीमित हैं जो आप URL का उपयोग करके संवाद कर सकते हैं।
  3. मेटाडेटा को नाम-मूल्य जोड़े (पोस्ट डेटा और क्वेरी स्ट्रिंग पैरामीटर) के रूप में पारित किया जाता है।

इसके बाद, अनुकूलन, कोडिंग सम्मेलनों और सर्वोत्तम प्रथाओं के बारे में बहस में पड़ना आसान है।

दिलचस्प बात यह है कि शोध प्रबंध में HTTP POST, GET, DELETE, या PUT संचालन का कोई उल्लेख नहीं है। किसी "वर्दी इंटरफ़ेस" के लिए "सर्वोत्तम अभ्यास" की किसी की बाद में व्याख्या होनी चाहिए।

जब वेब सेवाओं की बात आती है, तो ऐसा लगता है कि हमें डब्ल्यूएसडीएल और एसओएपी आधारित आर्किटेक्चर को अलग करने के कुछ तरीके की आवश्यकता है जो कि इंटरफेस में काफी ओवरहेड और यकीनन बहुत अनावश्यक जटिलता जोड़ते हैं। उन्हें लागू करने के लिए अतिरिक्त रूपरेखा और डेवलपर टूल की भी आवश्यकता होती है। मुझे यकीन नहीं है कि REST सामान्य-ज्ञान इंटरफेस और अत्यधिक इंजीनियर इंटरफेस जैसे WSDL और SOAP के बीच अंतर करने के लिए सबसे अच्छा शब्द है। लेकिन हमें कुछ चाहिए।


17

आरईएस एक वास्तुशिल्प पैटर्न और लेखन अनुप्रयोगों की शैली है। यह संकीर्ण अर्थों में एक प्रोग्रामिंग शैली नहीं है।

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

घरेलू शैलियों के विपरीत REST को कठिन समय लगातार और व्यावहारिक रूप से लागू करने में पड़ा है। यह जानबूझकर किया गया हो सकता है। इसके वास्तविक क्रियान्वयन को छोड़कर डिजाइनर तक। तो आप ऐसा करने के लिए स्वतंत्र हैं, जब तक आप उस अवरोध में स्थापित बाधाओं को पूरा करते हैं जो आप REST सिस्टम बना रहे हैं।

बक्शीश:

संपूर्ण वेब REST पर आधारित है (या REST वेब पर आधारित था)। इसलिए एक वेब डेवलपर के रूप में आप इसके बारे में जानना चाहते हैं, हालांकि अच्छे वेब ऐप लिखना आवश्यक नहीं है।


17

यहाँ REST की मेरी मूल रूपरेखा है। मैंने प्रत्येक घटक के पीछे की सोच को एक Restful वास्तुकला में प्रदर्शित करने की कोशिश की ताकि अवधारणा को समझना अधिक सहज हो। उम्मीद है कि यह कुछ लोगों के लिए REST को नष्ट करने में मदद करता है!

REST (प्रतिनिधि राज्य स्थानांतरण) एक डिज़ाइन आर्किटेक्चर है जो यह बताता है कि नेटवर्क संसाधनों (यानी नोड्स जो जानकारी साझा करते हैं) डिज़ाइन और संबोधित किए जाते हैं। सामान्य तौर पर, एक RESTful आर्किटेक्चर इसे बनाता है ताकि क्लाइंट (रिक्वेस्ट मशीन) और सर्वर (रिस्पांस मशीन) क्लाइंट के बिना डेटा को पढ़ने, लिखने और अपडेट करने का अनुरोध कर सके, ताकि यह पता चले कि सर्वर कैसे चल रहा है और सर्वर पास हो सकता है यह ग्राहक के बारे में कुछ भी जानने की आवश्यकता के बिना वापस। ठीक है, शांत ... लेकिन हम व्यवहार में यह कैसे करते हैं?

  • सबसे स्पष्ट आवश्यकता यह है कि किसी प्रकार की एक सार्वभौमिक भाषा होने की आवश्यकता है ताकि सर्वर क्लाइंट को बता सके कि वह अनुरोध के साथ क्या करने की कोशिश कर रहा है और सर्वर जवाब देने के लिए।

  • लेकिन किसी भी दिए गए संसाधन को खोजने के लिए और फिर उस ग्राहक को बताएं जहां वह संसाधन रहता है, संसाधनों पर इंगित करने का एक सार्वभौमिक तरीका होना चाहिए। यह वह जगह है जहाँ यूनिवर्सल रिसोर्स आइडेंटिफ़ायर (URI) आते हैं; वे मूल रूप से संसाधनों को खोजने के लिए अद्वितीय पते हैं।

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

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

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

  • आखिरी बात जो आप अक्सर यहाँ के वास्तुशिल्प के बारे में बताएंगे, वह यह है कि वे स्तरित हैं। हम वास्तव में पहले से ही ग्राहक और सर्वर के बीच बातचीत की हमारी चर्चा में इस आवश्यकता पर चर्चा कर रहे हैं। मूल रूप से, इसका मतलब है कि हमारे सिस्टम में प्रत्येक परत केवल आसन्न परतों के साथ बातचीत करती है। इसलिए हमारी चर्चा में, क्लाइंट लेयर हमारे सर्वर लेयर (और इसके विपरीत) के साथ इंटरैक्ट करता है, लेकिन अन्य सर्वर लेयर्स हो सकती हैं जो प्राथमिक सर्वर प्रोसेस को रिक्वेस्ट करने में मदद करती हैं जिससे क्लाइंट सीधे संवाद नहीं करता। बल्कि, सर्वर अनुरोध पर आवश्यक रूप से गुजरता है।

अब, अगर यह सब परिचित लगता है, तो महान है। हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP), जो वर्ल्ड वाइड वेब के माध्यम से संचार प्रोटोकॉल को परिभाषित करता है, Restful वास्तुकला की अमूर्त धारणा (या REST वर्ग का एक उदाहरण यदि आप मेरे जैसे ओओपी कट्टरपंथी हैं) का कार्यान्वयन है। REST के इस कार्यान्वयन में, क्लाइंट और सर्वर GET, POST, PUT, DELETE, आदि के माध्यम से बातचीत करते हैं, जो सार्वभौमिक भाषा का हिस्सा हैं और संसाधन URL का उपयोग करने के लिए इंगित किए जा सकते हैं।


15

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

इंटरनेट युग में प्रोग्रामिंग के मूलभूत परिवर्तनों को संभालने के लिए यह सबसे अच्छा व्यावहारिक तरीका है। मूलभूत परिवर्तनों के बारे में, एरिक मीजेर के यहाँ शो पर एक चर्चा है: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 । वह इसे पांच प्रभावों के रूप में सारांशित करता है, और एक समाधान को प्रोग्रामिंग भाषा में डिज़ाइन करके समाधान प्रस्तुत करता है। समाधान, भाषा की परवाह किए बिना, प्लेटफ़ॉर्म या सिस्टम स्तर में भी प्राप्त किया जा सकता है। बाकी को मौजूदा समाधानों में से एक के रूप में देखा जा सकता है जो मौजूदा अभ्यास में बहुत सफल रहा है।

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

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

बस मेरा 2 सी।

संपादित करें: दो और महत्वपूर्ण पहलू:


1
एक एमवीसी दृष्टिकोण: ब्लॉग रेस्ट वर्स्ट प्रैक्टिस ने मॉडल और संसाधनों को भ्रमित नहीं करने का सुझाव दिया । Django की किताब टू स्कूप्स बताती है कि रेस्ट एपीआई एक नजरिया है, न कि बिजनेस लॉजिक को देखने के लिए। ऐप के लिए कोड ऐप में रहना चाहिए।
मिंगहुआ


14

यह आश्चर्यजनक रूप से लंबी "चर्चा" है और अभी तक कम से कम कहने के लिए काफी भ्रामक है।

IMO:

1) एक बड़ा संयुक्त और बहुत सारे बीयर के बिना, आराम से प्रोग्राम करने जैसी कोई चीज नहीं है :)

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

आप (काफी) बाधाओं को संक्षेप में बता सकते हैं:

  • स्टेटलेस संचार
  • सम्मान HTTP चश्मा (यदि HTTP का उपयोग किया जाता है)
  • स्पष्ट रूप से प्रेषित सामग्री प्रारूपों का संचार करता है
  • हाइपरमीडिया का उपयोग एप्लिकेशन स्टेट के इंजन के रूप में करें

एक और बहुत अच्छी पोस्ट है जो चीजों को अच्छी तरह से समझाती है।

बहुत सारे उत्तर, मान्य जानकारी को कॉपी / पेस्ट करते हैं और कुछ भ्रम जोड़ते हैं। लोग यहां स्तरों के बारे में बात करते हैं, RESTFul URI के बारे में (ऐसी कोई बात नहीं है!), HTTP तरीकों को लागू करें GET, POST, PUT ... REST उस बारे में या केवल उसी के बारे में नहीं है।

उदाहरण के लिंक के लिए - खूबसूरती से दिखने वाली एपीआई के लिए अच्छा है लेकिन अंत में क्लाइंट / सर्वर को आपके द्वारा प्राप्त लिंक की वास्तव में परवाह नहीं है / भेजना यह ऐसी सामग्री है जो मायने रखती है।

अंत में कोई भी Restful ग्राहक किसी भी Restful सेवा का उपभोग करने में सक्षम होना चाहिए जब तक कि सामग्री प्रारूप ज्ञात नहीं हो जाता है।


14

पुराना सवाल, जवाब देने का नया तरीका। इस अवधारणा के बारे में कई गलत धारणाएं हैं। मैं हमेशा याद रखने की कोशिश करता हूं:

  1. संरचित URL और Http Methods / Verbs, रेफ़रिंग प्रोग्रामिंग की परिभाषा नहीं हैं।
  2. JSON आराम से प्रोग्रामिंग नहीं है
  3. RESTful प्रोग्रामिंग API के लिए नहीं है

मैं आराम करने वाली प्रोग्रामिंग को परिभाषित करता हूं

एक अनुप्रयोग आराम कर रहा है अगर यह मीडिया प्रदान करता है, तो ग्राहक को समझने वाले संसाधन (डेटा + राज्य संक्रमण नियंत्रण के संयोजन) प्रदान करता है

एक आराम करने वाला प्रोग्रामर बनने के लिए आपको ऐसे एप्लिकेशन बनाने की कोशिश करनी चाहिए जो अभिनेताओं को चीजें करने की अनुमति दें। सिर्फ डेटाबेस को उजागर नहीं कर रहा है।

राज्य संक्रमण नियंत्रण केवल तभी समझ में आता है जब ग्राहक और सर्वर संसाधन के मीडिया प्रकार के प्रतिनिधित्व पर सहमत होते हैं। अन्यथा यह जानने का कोई तरीका नहीं है कि एक नियंत्रण क्या है और एक नियंत्रण निष्पादित करने के लिए क्या और कैसे नहीं है। IE अगर ब्राउज़र <form>html में टैग नहीं जानते थे, तो आपके ब्राउज़र में संक्रमण राज्य में जमा करने के लिए आपके पास कुछ भी नहीं होगा।

मैं स्वयं को बढ़ावा देने के लिए नहीं देख रहा हूं, लेकिन मैं अपनी बात में इन विचारों पर बहुत गहराई से विस्तार करता हूं http://techblog.bodybuild.com/2016/01/video-what-is-restful-200.html

मेरी बात का एक अंश अक्सर रिचर्डसन मैच्योरिटी मॉडल के बारे में बताया गया है, मुझे स्तरों पर विश्वास नहीं है, आप या तो रेस्टफुल (लेवल 3) हैं या आप नहीं हैं, लेकिन मुझे इस बारे में कॉल करना पसंद है कि प्रत्येक स्तर क्या है आप के लिए अपने रास्ते पर करने के लिए करता है

एनोटेट किया गया रिचर्डसन परिपक्वता मॉडल


12

REST 6 वास्तु बाधाओं को परिभाषित करता है जो किसी भी वेब सेवा को बनाते हैं - एक सच्चा RESTful API

  1. यूनिफ़ॉर्म इंटरफ़ेस
  2. क्लाइंट सर्वर
  3. राज्यविहीन
  4. संचित करने योग्य
  5. स्तरित प्रणाली
  6. मांग पर कोड (वैकल्पिक)

https://restfulapi.net/rest-architectural-constraints/


फील्डिंग ने कुछ और नियम जोड़े
Restful

11

REST === HTTP सादृश्य तब तक सही नहीं है जब तक आप इस तथ्य पर जोर न दें कि यह "MUST" होना चाहिए HATEOAS

रॉय ने खुद यहां सफाई दी

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

[यहाँ असफलता का अर्थ है कि बाहर की जानकारी हाइपरटेक्स्ट के बजाय बातचीत चला रही है।]


दूसरों के रूप में स्वागत के रूप में सवाल का जवाब नहीं है, लेकिन प्रासंगिक जानकारी के लिए +1!
KGCybeX

मुझे लगता है कि यह सवाल का जवाब भी देता है, लेकिन उदाहरण के लिए स्टेटलेसनेस इससे गायब है। हर बाधा महत्वपूर्ण है ... मानक मीडिया प्रकार का हिस्सा हमेशा सच नहीं होता है। मेरा मतलब है कि समझ की परतें हैं। उदाहरण के लिए यदि आप आरडीएफ का उपयोग करते हैं, तो मीडिया प्रकार को समझा जा सकता है, लेकिन सामग्री का अर्थ नहीं। इसलिए क्लाइंट को शब्दावली भी जानना आवश्यक है। कुछ लोग इस तरह के REST API और हाइपरलिंक आदि का वर्णन करने के लिए एक सामान्य REST वोकैब का प्रयोग कर रहे हैं। वोकैब के सके hydra-cg.com
inf3rno

11

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 विधियां विशिष्ट हैं। निम्न तालिका इन कार्यों का स्पष्टीकरण देती है।

  • GET साइड-इफ़ेक्ट के बिना संसाधन की रीडिंग एक्सेस को परिभाषित करता है। संसाधन को GET अनुरोध के माध्यम से कभी नहीं बदला जाता है, उदाहरण के लिए, अनुरोध का कोई साइड इफेक्ट (idempotent) नहीं है।
  • PUT एक नया संसाधन बनाता है। यह भी अनिवार्य होना चाहिए।
  • DELETE संसाधनों को हटा देता है। ऑपरेशन बेकार हैं। वे विभिन्न परिणामों के लिए अग्रणी के बिना दोहराया जा सकता है।
  • POST एक मौजूदा संसाधन को अपडेट करता है या एक नया संसाधन बनाता है।

कई उद्धरण, लेकिन एक भी स्रोत का उल्लेख नहीं किया गया है। तुम्हें यह कहाँ मिला?
djvg

10

REST का अर्थ है प्रतिनिधि राज्य हस्तांतरण

यह एक स्टेटलेस, क्लाइंट-सर्वर, कैशेबल संचार प्रोटोकॉल पर निर्भर करता है - और लगभग सभी मामलों में, HTTP प्रोटोकॉल का उपयोग किया जाता है।

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

रेस्ट के बारे में परिचय


10

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


10

"रेस्टफुल प्रोग्रामिंग" प्रति se जैसी धारणा नहीं है। इसे बेहतर Restful प्रतिमान या इससे भी बेहतर Restful वास्तुकला कहा जाएगा। यह एक प्रोग्रामिंग भाषा नहीं है। यह एक प्रतिमान है।

विकिपीडिया से :

कंप्यूटिंग में, प्रतिनिधित्वात्मक राज्य हस्तांतरण (REST) ​​एक वास्तुशिल्प शैली है जिसका उपयोग वेब विकास के लिए किया जाता है।


9

आराम की बात यह है कि अगर हम बुनियादी कार्यों (http क्रिया) के लिए एक सामान्य भाषा का उपयोग करने के लिए सहमत हैं, तो बुनियादी ढांचे को उन्हें समझने और उन्हें ठीक से अनुकूलित करने के लिए कॉन्फ़िगर किया जा सकता है, उदाहरण के लिए, कैशिंग हेडर का उपयोग करके कैशिंग को बिल्कुल लागू करने के लिए। स्तरों।

ठीक से लागू किए गए आराम से GET ऑपरेशन के साथ, यदि आपके सर्वर की DB, आपके सर्वर का मेमेक, CDN, प्रॉक्सी का कैश, आपके ब्राउज़र का कैश या आपके ब्राउज़र का स्थानीय संग्रहण से जानकारी आती है, तो इससे कोई फर्क नहीं पड़ता। उपवास, सबसे आसानी से उपलब्ध स्रोत तक उपयोग किया जा सकता है।

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


5
"यह कहना कि रेस्ट सिर्फ एक वाक्यात्मक परिवर्तन है ... यह ऐसा दिखता है कि इसका कोई लाभ नहीं है और विशुद्ध रूप से कॉस्मेटिक है" --- यही कारण है कि मैं एसओ पर यहां जवाब पढ़ रहा हूं। ध्यान दें कि आपने समझाया नहीं, क्यों REST विशुद्ध रूप से कॉस्मेटिक नहीं है।
osa

5

एपीआई परीक्षण क्या है ?

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

बाकी एपीआई

बाकी: प्रतिनिधि राज्य स्थानांतरण।

  • यह उन कार्यों की व्यवस्था है जिन पर परीक्षक अनुरोध करते हैं और प्रतिक्रियाएँ प्राप्त करते हैं। REST API में HTTP प्रोटोकॉल के जरिए बातचीत की जाती है।
  • REST एक नेटवर्क पर एक दूसरे के साथ कंप्यूटर के बीच संचार की भी अनुमति देता है।
  • संदेश भेजने और प्राप्त करने के लिए, इसमें HTTP विधियों का उपयोग करना शामिल है, और इसे वेब सेवाओं के विपरीत एक सख्त संदेश परिभाषा की आवश्यकता नहीं है।
  • अन्य संदेश अक्सर XML या जावास्क्रिप्ट ऑब्जेक्ट नोटेशन (JSON) के रूप में फॉर्म को स्वीकार करते हैं।

4 आमतौर पर इस्तेमाल किया एपीआई तरीके: -

  1. GET: - यह एक संसाधन तक केवल पढ़ने की सुविधा प्रदान करता है।
  2. POST: - इसका उपयोग एक नया संसाधन बनाने या अपडेट करने के लिए किया जाता है।
  3. PUT: - इसका उपयोग किसी मौजूदा संसाधन को अपडेट करने या बदलने या एक नया संसाधन बनाने के लिए किया जाता है।
  4. DELETE: - इसका उपयोग किसी संसाधन को निकालने के लिए किया जाता है।

मैन्युअल रूप से एपीआई परीक्षण करने के लिए कदम: -

API का उपयोग मैन्युअल रूप से करने के लिए, हम ब्राउज़र आधारित REST API प्लग इन का उपयोग कर सकते हैं।

  1. POSTMAN (Chrome) / REST (फ़ायरफ़ॉक्स) प्लगइन स्थापित करें
  2. API URL दर्ज करें
  3. REST विधि का चयन करें
  4. सामग्री-हेडर चुनें
  5. अनुरोध JSON (POST) दर्ज करें
  6. सेंड पर क्लिक करें
  7. यह आउटपुट रेस्पॉन्स लौटाएगा

रीस्ट एपीआई को स्वचालित करने के लिए कदम


5
यह भी एक उचित जवाब नहीं है
उपचारात्मक सुशासन

5

यह हर जगह बहुत कम उल्लिखित है, लेकिन रिचर्डसन की परिपक्वता मॉडल वास्तव में जज करने के लिए सबसे अच्छा तरीकों में से एक है कि कोई व्यक्ति कितना आराम करता है। इसके बारे में यहाँ और अधिक:

रिचर्डसन की परिपक्वता मॉडल


अगर आप बाधाओं को देखते हुए REST पर लगाई गई फील्डिंग को देखेंगे तो आप स्पष्ट रूप से देखेंगे कि एक RM को RMM के लेयर 3 तक पहुंचने की आवश्यकता है ताकि इसे RESTful के रूप में देखा जा सके, हालांकि यह वास्तव में पर्याप्त नहीं है क्योंकि अभी भी असफल होने की पर्याप्त संभावनाएं हैं REST विचार - सर्वर API से क्लाइंट का डिकॉप्लिंग। ज़रूर, लेयर 3 HATEOAS बाधा को पूरा करता है, लेकिन यह अभी भी आवश्यकताओं को तोड़ने के लिए और ग्राहकों को कसकर एक सर्वर (यानी टाइप किए गए संसाधनों का उपयोग करके) को आसान करने के लिए आसान है
रोमन वोटर

2

मैं कहूंगा कि REST समझने में एक महत्वपूर्ण बिल्डिंग ब्लॉक एंडपॉइंट या मैपिंग में निहित है, जैसे /customers/{id}/balance

आप अपने डेटाबेस / सर्वर (बैक-एंड) के लिए वेबसाइट (फ्रंट-एंड) से कनेक्टिंग पाइपलाइन होने के रूप में इस तरह के एक समापन बिंदु की कल्पना कर सकते हैं। उनका उपयोग करते हुए, फ्रंट-एंड बैक-एंड ऑपरेशन कर सकता है जो आपके एप्लिकेशन में किसी भी REST मैपिंग के संबंधित तरीकों में परिभाषित किए गए हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.