REST API - PUT DELETE POST GET का उपयोग क्यों करें?

Question

इसलिए, मैं REST API के निर्माण के कुछ लेख देख रहा था। और उनमें से कुछ सभी प्रकार के HTTP अनुरोधों का उपयोग करने का सुझाव देते हैं: जैसे PUT DELETE POST GET। हम उदाहरण index.php के लिए बनाएंगे और एपीआई को इस तरह से लिखेंगे:

$method = $_SERVER['REQUEST_METHOD'];
$request = split("/", substr(@$_SERVER['PATH_INFO'], 1));

switch ($method) {
  case 'PUT':
    ....some put action.... 
    break;
  case 'POST':
    ....some post action.... 
    break;
  case 'GET':
    ....some get action.... 
    break;
  case 'DELETE':
    ....some delete action.... 
    break;
}

ठीक है, दी गई - मुझे वेब सेवाओं (अभी तक) के बारे में ज्यादा जानकारी नहीं है। लेकिन, क्या JSON ऑब्जेक्ट को नियमित रूप से स्वीकार करना आसान नहीं होगा POSTया GET(जिसमें विधि नाम और सभी पैरामीटर शामिल होंगे) और फिर JSON में भी इसका जवाब देंगे। हम आसानी से PHP के माध्यम से क्रमिक / deserialize कर सकते हैं json_encode()और json_decode()विभिन्न HTTP अनुरोध विधियों से निपटने के लिए बिना उस डेटा के साथ जो कुछ भी हम चाहते हैं।

क्या मैं कुछ भूल रहा हूँ?

अद्यतन 1:

ठीक है - विभिन्न एपीआई के माध्यम से खुदाई करने और XML-RPC , JSON-RPC , SOAP , REST के बारे में बहुत कुछ जानने के बाद मैं इस निष्कर्ष पर पहुंचा कि इस प्रकार का एपीआई ध्वनि है। वास्तव में स्टैक एक्सचेंज अपनी साइटों पर इस दृष्टिकोण का उपयोग करके बहुत अधिक है और मुझे लगता है कि इन लोगों को पता है कि वे स्टैक एक्सचेंज एपीआई क्या कर रहे हैं ।

Comments

एक JSON पेलोड को क्यों मजबूर करें? क्या होगा अगर कोई JSON नहीं है, और यह एक सादा पुराना GET है?

— माइक डीस्मोन

हाँ। w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9

— इग्नासियो

Answer 1

आरई प्रेजेंटेशनल एस टेट टी का विचार रैन्सर का डेटा को सरलतम तरीके से एक्सेस करने के बारे में नहीं है।

आपने JSON तक पहुंचने के लिए पोस्ट अनुरोधों का उपयोग करने का सुझाव दिया, जो डेटा तक पहुंचने / हेरफेर करने के लिए एक पूरी तरह से वैध तरीका है।

REST अर्थपूर्ण के लिए एक पद्धति है डेटा की पहुंच के । जब आप REST में एक अनुरोध देखते हैं, तो यह तुरंत ही होना चाहिए कि डेटा के साथ क्या हो रहा है।

उदाहरण के लिए:

GET: /cars/make/chevrolet

संभावना है कि चेवी कारों की सूची वापस आ जाएगी। एक अच्छा REST एपि भी कुछ आउटपुट विकल्पों को क्वेरिस्ट्रिंग में शामिल कर सकता है जैसे ?output=jsonया ?output=htmlजो एक्सेसर को यह तय करने की अनुमति देगा कि सूचना को किस प्रारूप में एन्कोड किया जाना चाहिए।

के बारे में कैसे एक REST API में यथोचित शामिल डेटा टाइपिंग के लिए सोच का एक सा के बाद, मुझे लगता है कि सबसे अच्छा तरीका स्पष्ट रूप से डेटा के प्रकार को निर्दिष्ट करने की तरह के रूप में पहले से ही विद्यमान फाइल एक्सटेंशन के माध्यम से किया जाएगा यह निष्कर्ष निकाला गया है .js, .json, .html, या .xml। एक लापता फ़ाइल एक्सटेंशन जो भी प्रारूप डिफ़ॉल्ट है (जैसे JSON); फ़ाइल एक्सटेंशन जो समर्थित नहीं है, एक 501 Not Implementedस्थिति कोड लौटा सकता है ।

एक और उदाहरण:

POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }

संभवतः संबंधित रंगों के साथ db में एक नया चेवी मालिबू बनाने जा रहा है। मैं कहता हूँ की संभावना के रूप में REST API सीधे डेटाबेस संरचना से संबंधित होने की जरूरत नहीं है। यह सिर्फ एक मास्किंग इंटरफ़ेस है ताकि सही डेटा संरक्षित हो (डेटाबेस संरचना के लिए एक्सेसर्स और म्यूटेटर की तरह सोचें)।

अब हमें मूर्तिपूजा के मुद्दे पर आगे बढ़ने की आवश्यकता है । सामान्यतः REST HTTP पर CRUD को लागू करता है। HTTP का उपयोग करता है GET, PUT, POSTऔर DELETEअनुरोधों के लिए।

REST का एक बहुत ही सरल कार्यान्वयन निम्नलिखित CRUD मैपिंग का उपयोग कर सकता है :

Create -> Post
Read   -> Get
Update -> Put
Delete -> Delete

इस कार्यान्वयन के साथ एक समस्या है: पोस्ट को एक गैर-बेरोजगारी विधि के रूप में परिभाषित किया गया है। इसका मतलब यह है कि एक ही पोस्ट विधि के बाद के कॉल का परिणाम विभिन्न सर्वर राज्यों में होगा। Get, Put, and Delete, idempotent हैं; जिसका अर्थ है कि उन्हें कई बार कॉल करने का परिणाम एक समान सर्वर स्थिति में होना चाहिए।

इसका मतलब है कि एक अनुरोध:

Delete: /cars/oldest

वास्तव में के रूप में लागू किया जा सकता है:

Post: /cars/oldest?action=delete

जहाँ तक

Delete: /cars/id/123456

यदि आप इसे एक बार कॉल करते हैं, या यदि आप इसे 1000 बार कॉल करते हैं, तो उसी सर्वर स्थिति में परिणाम होगा।

oldestआइटम को हटाने का एक बेहतर तरीका अनुरोध करना होगा:

Get: /cars/oldest

और अनुरोध IDकरने के लिए परिणामी डेटा से उपयोग करें delete:

Delete: /cars/id/[oldest id]

इस पद्धति के साथ एक समस्या यह होगी कि /carsजब /oldestअनुरोध किया गया था और कब deleteजारी किया गया था के बीच एक और आइटम जोड़ा गया था।

Comments

@ और यह कई कारणों का एक संयोजन है: HTTP दिशानिर्देशों का पालन करने का मतलब है कि जब चीजें बदल जाएंगी तो आपको (संभवतः) कम बैकवर्ड संगतता समस्याएं होंगी; POST के माध्यम से एक HTML फॉर्म का उपयोग करने से उपयोगकर्ता को एक ही डेटा के कई सबमिशन के लिए चेतावनी दी जाएगी (यह एक गैर-आय वाले लेनदेन को रोकने के लिए है); एक अच्छी तरह से परिभाषित सबसे अच्छा अभ्यास के बाद, अच्छी तरह से..बहुत अभ्यास है। बाकी को एक विशिष्ट कार्यान्वयन को ध्यान में नहीं रखा गया है, जो आपको फिट दिखने के साथ इसका उपयोग करने की अनुमति देता है। मैं सुझाव देता हूँ कि आप HTTP के सभी त्रुटि कोड और अनुरोध के तरीकों का लाभ उठाएँ, लेकिन आपको इसे वैसे ही करने की अनुमति है

— zzzzBov

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

— मर्लिन मॉर्गन-ग्राहम

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

— मेरीलिन मॉर्गन-ग्राहम

DELETE के बजाय: / कारें / सबसे पुरानी, ​​GET के बारे में कैसे: / कारें / सबसे पुरानी एक DELETE द्वारा पीछा की जाती हैं? इस तरह, आपके पास दो अलग-अलग idempotent कमांड हैं।

— नील

+1; मैं मानता हूँ कि यह एक अच्छा जवाब है (मैं इसे फिर से मज़े और लाभ के लिए ले रहा हूँ) POST: /cars/oldestएक DELETE के लिए एक प्रतिस्थापन होने का कोई मतलब नहीं है। कुछ ऐसा है - POST: /cars/oldest/deleteहो सकता है, मुझे लगता है कि मुझे नील का समाधान बेहतर लगता है। एकमात्र लाभ जो सीधे डिलीट करने पर उसके गेट-आईडी-डिलीट-आईडी समाधान से अधिक होता है, वह है परमाणुता। इससे पहले कि मैं इस तरह की चीज को लागू करूं, मैं गैर-विवादास्पद परिदृश्य के साथ एक स्पष्ट व्यापार औचित्य चाहता हूं। आपको सभी ऑब्जेक्ट्स / यूआरएल पर सभी क्रियाओं का समर्थन करने की आवश्यकता नहीं है।

— मेरलिन मॉर्गन-ग्राहम

Answer 2

यह सुरक्षा और स्थिरता का सवाल है।

सुरक्षित तरीके

जब भी संभव हो, आपको संभावित भेद्यता को सीमित करने के लिए GET और HEAD जैसे 'सुरक्षित' (यूनिडायरेक्शनल) तरीकों का उपयोग करना चाहिए।

आलंकारिक तरीके

जब भी संभव हो, आपको GET, HEAD, PUT और DELETE जैसे emp idempotent ’विधियों का उपयोग करना चाहिए, जिनके दुष्प्रभाव नहीं हो सकते हैं और इसलिए कम त्रुटि वाले / नियंत्रित करने में आसान हैं।

स्रोत

Comments

क्षमा करें, लेकिन PUT और DELETE idempotent तरीके कैसे हैं? वे सर्वर की स्थिति और उसके डेटा को प्रभावित करते हैं!

— महमूद अल-कुद्सी

@ कंप्यूटर: एक ही PUT या एक ही DELETE करने से एक ही अंतिम स्थिति में परिणाम मिलता है। यही "इडम्पोटेंट" का अर्थ है।

— इग्नासियो वाज़क्वेज़-अब्राम्स

अधिक स्पष्टीकरण के लिए: यदि कोई एकल अनुप्रयोग और उसके कई परिणामी अनुप्रयोग दोनों एक ही परिणाम लौटाते हैं, तो एक ऑपरेशन F, निरर्थक है। यदि एफ केवल (x) = F (F (x)) है, तो अधिक सटीक एफ आदर्श है। उदाहरण के लिए, डिलीट इम्पोटेंट है, क्योंकि जब आप किसी आइटम को एक बार डिलीट करते हैं, या उसे कई बार हटाते हैं, तो परिणाम समान होता है: डिलीट फर्स्ट एप्लिकेशन के साथ आइटम को केवल एक बार डिलीट किया जाता है और डिलीट सेकंड या थर्ड एप्लिकेशन में कुछ भी नहीं होता है।

— qartal

लेकिन निर्माण के संदर्भ में, जब आप एक बनाएँ कमांड के साथ एक नया रिकॉर्ड बनाते हैं, और उसी कमांड को फिर से जारी करते हैं, तो दो रिकॉर्ड (संभवत:) बनाया जाता है (हालांकि दोनों एक ही जानकारी को दर्शाते हैं)।

— १al

qartal - idempotent के लिए आपकी कार्यात्मक परिभाषा 'F (X) = F (X) F (X)' होनी चाहिए। हालांकि यह वाक्यांश के लिए अच्छा तरीका है।

— जेरार्ड ओनील

Answer 3

संक्षेप में, REST क्रियाओं पर संज्ञाओं पर जोर देता है। जैसे-जैसे आपका API अधिक जटिल होता जाता है, आप अधिक आज्ञाओं के बजाय अधिक चीजें जोड़ते जाते हैं।

Comments

मुझे अपने सिर को गोल करने में थोड़ी परेशानी हुई। यह पोस्ट ( lornajane.net/posts/2013/… ) कि क्रिया HTTP रिक्वेस्ट से आनी चाहिए ताकि URI को तब ही संज्ञा सम्‍मिलित हो, मेरे लिए यह एक टैड है

— icc97

Answer 4

आपने पूछा :

केवल $ _POST के माध्यम से JSON ऑब्जेक्ट को स्वीकार करना आसान नहीं होगा और फिर JSON में भी जवाब देंगे

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

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

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

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

दूसरी ओर, HTTP पर SOAP RPC, संज्ञा और क्रियाओं की एक नई और मनमानी शब्दावली को परिभाषित करने के लिए प्रत्येक एप्लिकेशन डिज़ाइनर को प्रोत्साहित करती है (उदाहरण के लिए getUsers (), savePurchaseOrder (...)), जो आमतौर पर HTTP 'POST' क्रिया से अधिक होता है। यह HTTP की कई मौजूदा क्षमताओं जैसे कि प्रमाणीकरण, कैशिंग और सामग्री प्रकार की बातचीत की उपेक्षा करता है, और नई शब्दावली के भीतर इनमें से कई सुविधाओं को फिर से आविष्कार करने वाला एप्लिकेशन डिज़ाइनर छोड़ सकता है।

आप जिन वास्तविक वस्तुओं के साथ काम कर रहे हैं, वे किसी भी प्रारूप में हो सकते हैं। विचार यह है कि उपयोगकर्ता उन संसाधनों (क्वेरी, राज्य प्रबंधन / उत्परिवर्तन, विलोपन) पर प्रदर्शन करना चाहता है, जो आपके संचालन को उजागर करने के लिए जितना संभव हो उतना HTTP का पुन: उपयोग करना है।

आपने पूछा :

क्या मैं कुछ भूल रहा हूँ?

REST और URI सिंटैक्स / HTTP क्रियाओं के बारे में स्वयं जानने के लिए बहुत कुछ है। उदाहरण के लिए, कुछ क्रियाएं निष्प्राण हैं, अन्य नहीं हैं। मुझे आपके प्रश्न में इसके बारे में कुछ भी दिखाई नहीं दिया, इसलिए मैंने इसमें गोता लगाने की कोशिश नहीं की। अन्य उत्तर और विकिपीडिया दोनों में बहुत अच्छी जानकारी है।

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

Answer 5

डेटा प्रकार को परिभाषित करने के लिए एक्सटेंशन का उपयोग करने के संबंध में। मैंने देखा कि MailChimp API ऐसा कर रहा है, लेकिन मुझे नहीं लगता कि यह एक अच्छा विचार है।

GET /zzz/cars.json/1

GET /zzz/cars.xml/1

एक अच्छे विचार की तरह मेरी आवाज़, लेकिन मुझे लगता है कि "पुराने" दृष्टिकोण बेहतर है - HTTP हेडर का उपयोग करना

GET /xxx/cars/1
Accept: application/json

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

POST /zzz/cars
Content-Type: application/xml     <--- indicates we sent XML to server
Accept: application/json          <--- indicates we want get data back in JSON format  

Answer 6

क्या मैं कुछ भूल रहा हूँ?

हाँ। ;-)

यूनिफ़ॉर्म इंटरफ़ेस की कमी के कारण यह घटना मौजूद है । पहिया को फिर से स्थापित करने के बजाय पहले से मौजूद मानकों का उपयोग करना आरईएसटी को पसंद है। HTTP मानक पहले ही अत्यधिक स्केलेबल साबित हो चुका है (वेब ​​थोड़ी देर के लिए काम कर रहा है)। क्यों हम कुछ है जो टूट नहीं है ठीक करना चाहिए ?!

नोट: यदि आप सेवा से ग्राहकों को हटाना चाहते हैं तो यूनिफ़ॉर्म इंटरफ़ेस की कमी महत्वपूर्ण है। यह एक-दूसरे से अलग करने के लिए कक्षाओं के लिए इंटरफेस को परिभाषित करने के समान है। ऑप्टिकल फाइबर केबल। यहाँ एक समान इंटरफ़ेस में HTTP , MIME प्रकार , URI , RDF , लिंक्ड डेटा वोकैब , हाइड्रा वोकैट्स , आदि जैसे मानक हैं ...

Answer 7

प्रोग्रामिंग में अच्छा शब्दार्थ महत्वपूर्ण है।

GET / POST के अलावा और अधिक तरीकों का उपयोग करना सहायक होगा क्योंकि यह आपके कोड की पठनीयता को बढ़ाएगा और इसे बनाए रखना आसान बनाएगा।

क्यों?

क्योंकि आपको पता है कि GET आपके एपीआई से डेटा पुनः प्राप्त करेगा। आप जानते हैं कि POST आपके सिस्टम में नया डेटा जोड़ेगा। आपको पता है कि PUT अपडेट करेगा। DELETE पंक्तियों को हटा देगा आदि, आदि,

मैं आम तौर पर अपनी RESTFUL वेब सेवाओं की संरचना करता हूं ताकि मेरे पास फ़ंक्शन कॉलबैक विधि नाम की एक ही चीज़ हो।

मैं PHP का उपयोग करता हूं, इसलिए मैं function_exists का उपयोग करता हूं (मुझे लगता है कि यह कहा जाता है)। यदि फ़ंक्शन मौजूद नहीं है, तो मैं 405 (METHOD NOT ALLOWED) फेंक देता हूं।

Answer 8

बिल वेनर्स: आपके ब्लॉग पोस्ट में "Why REST Failed" शीर्षक से आपने कहा कि हमें सभी चार HTTP क्रियाओं- GET, POST, PUT, और DELETE- की आवश्यकता है और उस ब्राउज़र विक्रेताओं को केवल GET और POST की दुहाई दी। "हमें इन चारों की आवश्यकता क्यों है। क्यों पर्याप्त नहीं है?

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

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

PUT और DELETE GET और POST के बीच में हैं। PUT या DELETE और POST के बीच अंतर यह है कि PUT और DELETE * निष्क्रिय हैं, जबकि POST नहीं है। यदि आवश्यक हो तो PUT और DELETE दोहराया जा सकता है। मान लें कि आप किसी साइट पर एक नया पृष्ठ अपलोड करने का प्रयास कर रहे हैं। कहते हैं कि आप http://www.example.com/foo.html पर एक नया पृष्ठ बनाना चाहते हैं, तो आप अपनी सामग्री टाइप करें और आप इसे उस URL पर रखें। सर्वर उस URL पर वह पेज बनाता है जिसे आप सप्लाई करते हैं। अब, मान लीजिए कि किसी कारण से आपका नेटवर्क कनेक्शन डाउन हो जाता है। आपको यकीन नहीं है, अनुरोध के माध्यम से मिला या नहीं? शायद नेटवर्क धीमा है। शायद एक प्रॉक्सी सर्वर समस्या थी। इसलिए इसे फिर से आज़माना ठीक है, या फिर से-जैसा कि आप इसे पसंद करते हैं। क्योंकि एक ही डॉक्यूमेंट को एक ही URL पर दस बार डालने से एक बार डालने से कोई फर्क नहीं पड़ेगा। DELETE के लिए भी यही सच है। आप किसी चीज़ को दस बार डिलीट कर सकते हैं, और इसे एक बार डिलीट करने के समान है।

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

कृपया अधिक जानकारी के लिए url पर जाएं। http://www.artima.com/lejava/articles/why_put_and_delete.html

अपडेट करें:

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

निम्नलिखित उदाहरणों पर विचार करें:

a = 4;

एक ++;

पहला उदाहरण है उदासीन: हम इस कथन को कितनी ही बार अमल में लाएँ, एक इच्छा हमेशा 4 होगी। दूसरा उदाहरण यह नहीं है। इस 10 बार निष्पादित करने पर 5 बार चलने के रूप में एक अलग परिणाम होगा। चूँकि दोनों उदाहरण एक के मूल्य को बदल रहे हैं, दोनों गैर-सुरक्षित तरीके हैं।

Comments

एक नए पृष्ठ के उदाहरण के बारे में, क्या POST का उपयोग उस तरीके से नहीं किया जाना चाहिए, जबकि एक अपडेट के लिए PUT? एक नया पेज बनाना एक ऐसी प्रक्रिया है जो हर बार एक नया परिणाम प्राप्त करता है, जबकि एक ही संपादन को हर बार एक ही परिणाम को प्राप्त करते हुए, किसी भी राशि का पुन: भुगतान किया जा सकता है। हालांकि, अच्छा वाक्यांश और स्पष्टीकरण।

— स्पायर्टो

Answer 9

मूल रूप से REST है ( विकि ):

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

REST प्रोटोकॉल नहीं है, यह सिद्धांत है। अलग-अलग यूरिस और तरीके - किसी को तथाकथित सर्वोत्तम प्रथाओं।