POST के साथ अनुरोध बनाएं, जो 200 या 201 कोड का जवाब देता है और सामग्री


125

मान लीजिए कि मैं एक REST सेवा लिखता हूँ जिसका आशय एक सिस्टम में एक नया डेटा आइटम जोड़ना है।

मैं POST करने की योजना बना रहा हूं

http://myhost/serviceX/someResources

मान लीजिए कि काम करता है, मुझे किस प्रतिक्रिया कोड का उपयोग करना चाहिए? और मैं क्या सामग्री वापस कर सकता हूं।

मैं HTTP प्रतिक्रिया कोड की परिभाषाएँ देख रहा हूँ और इन संभावनाओं को देखता हूँ:

200: कार्रवाई के परिणाम का वर्णन करने या युक्त एक इकाई लौटें ;

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

उत्तरार्द्ध Http कल्पना के अनुरूप अधिक लगता है, लेकिन मैं बिल्कुल स्पष्ट नहीं हूं

प्रतिक्रिया SHOULD में संसाधन विशेषताओं और स्थान की सूची वाली एक इकाई शामिल है

माध्यम।

सिफारिशें? व्याख्याओं?

जवाबों:


77

विचार यह है कि प्रतिक्रिया निकाय आपको एक पृष्ठ देता है जो आपको चीज़ से जोड़ता है:

201 बनाया गया

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

इसका मतलब यह है कि आप एक Locationप्रतिक्रिया हैडर में शामिल होंगे जो उस URL को देता है जहाँ आप नई बनाई गई चीज़ पा सकते हैं :

HTTP/1.1 201 Created
Date: Sat, 02 Apr 2016 12:22:40 GMT
Location: http://stackoverflow.com/a/36373586/12597

प्रतिक्रिया शरीर

वे तब उल्लेख करते हैं कि आपको प्रतिक्रिया निकाय में क्या शामिल होना चाहिए :

201 प्रतिसाद पेलोड आम तौर पर बनाए गए संसाधन (लिंक) का वर्णन करता है और लिंक करता है।

ब्राउज़र का उपयोग करने वाले मानव के लिए, आप उन्हें कुछ ऐसा दे सकते हैं जो वे देख सकते हैं, और उनके नए बनाए गए संसाधन के लिए क्लिक कर सकते हैं:

HTTP/1.1 201 Created
Date: Sat, 02 Apr 2016 12:22:40 GMT
Location: http://stackoverflow.com/a/36373586/12597
Content-Type: text/html

Your answer has been saved! 
Click <A href="https://stackoverflow.com/a/36373586/12597">here</A> to view it.

यदि पेज केवल एक रोबोट द्वारा उपयोग किया जाएगा, तो यह प्रतिक्रिया करने के लिए समझ में आता है कि कंप्यूटर को पढ़ने योग्य होना चाहिए:

HTTP/1.1 201 Created
Date: Sat, 02 Apr 2016 12:22:40 GMT
Location: http://stackoverflow.com/a/36373586/12597
Content-Type: application/xml

<createdResources>
   <questionID>1860645</questionID>
   <answerID>36373586</answerID>
   <primary>/a/36373586/12597</primary>
   <additional>
      <resource>http://stackoverflow.com/questions/1860645/create-request-with-post-which-response-codes-200-or-201-and-content/36373586#36373586</resource>
      <resource>http://stackoverflow.com/a/1962757/12597</resource>
   </additional>
</createdResource>

या, यदि आप पसंद करते हैं:

HTTP/1.1 201 Created
Date: Sat, 02 Apr 2016 12:22:40 GMT
Location: http://stackoverflow.com/a/36373586/12597
Content-Type: application/json

{ 
   "questionID": 1860645, 
   "answerID": 36373586,
   "primary": "/a/36373586/12597",
   "additional": [
      "http://stackoverflow.com/questions/1860645/create-request-with-post-which-response-codes-200-or-201-and-content/36373586#36373586",
      "http://stackoverflow.com/a/36373586/12597"
   ]
}

प्रतिक्रिया पूरी तरह से आप पर निर्भर है; यह मनमाने ढंग से आप क्या चाहते हैं।

कैश फ्रेंडली

अंत में वहाँ अनुकूलन है कि मैं बनाए गए संसाधन को प्री-कैश कर सकता हूं (क्योंकि मेरे पास सामग्री पहले से है; मैंने अभी इसे अपलोड किया है)। सर्वर एक तारीख या ETag लौटा सकता है जिसे मैं अपने द्वारा अपलोड की गई सामग्री के साथ संग्रहीत कर सकता हूं:

अर्थ प्रतिक्रिया हेडर क्षेत्रों के अर्थ और उद्देश्य की चर्चा के लिए धारा 7.2 देखें , जैसे कि ईटाग और लास्ट-संशोधित, एक 201 प्रतिक्रिया में।

HTTP/1.1 201 Created
Date: Sat, 02 Apr 2016 12:22:40 GMT
Location: http://stackoverflow.com/a/23704283/12597
Content-Type: text/html
ETag: JF2CA53BOMQGU5LTOQQGC3RAMV4GC3LQNRSS4
Last-Modified: Sat, 02 Apr 2016 12:22:39 GMT 

Your answer has been saved! 
Click <A href="https://stackoverflow.com/a/36373586/12597">here</A> to view it.

और ETagविशुद्ध रूप से मनमाना मूल्य हैं। जब कोई संसाधन बदलता है (और कैश को अद्यतन करने की आवश्यकता होती है) तो यह सब अलग होता है। ETag आमतौर पर एक हैश (जैसे SHA2) है। लेकिन यह एक डेटाबेस rowversion, या एक वृद्धि संख्या संशोधन हो सकता है । कोई भी चीज जो होगा बदल जब बात बदल जाता है।


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

1
@ एंथनी, कैशिंग: यह एक तरह का 1: 1 फाइल स्टोरेज एप्लिकेशन हो सकता है। उदाहरण के लिए WebDAV PUT और POST की तुलना करें। विशाल फाइलें संभाला जाए।
kxr

@ यदि आप ग्राहक के लिए एक ETag वापस करना चाहते हैं तो यह आपके ऊपर है। यदि आपके द्वारा अभी अपलोड की गई सामग्री वह नहीं है जिसे आपने सहेजा है, तो ETag वापस न करें। यह आपके लचीलेपन और आपकी पसंद है।
इयान बॉयड

आपकी प्रतिक्रियाएं सामग्री-लंबाई क्यों याद कर रही हैं?
विन्नी फाल्को

1
@VinnieFalco यह 201 प्रतिक्रिया कोड के बारे में एक उत्तर है। कंटेंट-लेंथ एक्सपोजर उद्देश्यों के लिए बढ़ाई गई है।
इयान बॉयड

91

मुझे लगता है कि Atompub REST API एक आरामदायक सेवा का एक बेहतरीन उदाहरण है। नीचे की ओर से स्निपेट देखें

POST /edit/ HTTP/1.1
Host: example.org
User-Agent: Thingio/1.0
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
Slug: First Post

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>John Doe</name></author>
  <content>Some text.</content>
</entry>

सर्वर 201 के स्टेटस कोड के साथ एक सफल निर्माण का संकेत देता है। प्रतिक्रिया में एटम एंट्री के सदस्य एंट्री यूआरआई और प्रतिक्रिया के शरीर में उस एंट्री के प्रतिनिधित्व को इंगित करने वाला एक स्थान शीर्षलेख शामिल होता है।

HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/edit/first-post.atom
ETag: "c180de84f991g8"  

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>John Doe</name></author>
  <content>Some text.</content>
  <link rel="edit"
      href="http://example.org/edit/first-post.atom"/>
</entry>

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


9
निर्मित संसाधन को वापस करना थोड़ा अधिक हो सकता है, यदि संसाधन विशालकाय परिमाण में हो ...
Tor Valamo

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

3
@ चन्द्रपत्नी, परमाणु मर चुका है । बेहतर उदाहरण चाहिए।
पचेरियर

16
परमाणु मृत हो सकता है, लेकिन उदाहरण की आत्मा अभी भी हाजिर है।
आशिमा

2
201 की प्रतिक्रिया की मेरी मूल व्याख्या अधिक थी "हे, तुम एक संसाधन बनाना चाहते थे, लेकिन संदर्भ के आधार पर, आप या तो अंतिम परिणाम में रुचि नहीं रखते थे, या उन्होंने पहुंच लिखी है लेकिन इस संसाधन तक पहुंच नहीं पढ़ी है। या तो। मामला, मुख्य संग्रह पर लौटने से पहले आपको आवश्यक संसाधन का URL है। साक्ष्य के रूप में इसे बनाया गया था। " इससे परे कुछ भी 200 प्रतिक्रिया की तरह लगता है, अनिवार्य रूप से। जब तक RFC के मन में कुछ और था।
एंथनी

50

कुछ ही शब्दों में:

  • 200 जब कोई वस्तु बनाई जाती है और वापस आ जाती है
  • 201 जब कोई वस्तु बनाई जाती है, लेकिन केवल उसका संदर्भ लौटाया जाता है (जैसे आईडी या लिंक)

इसके लिए स्रोत?
सूदो आत्मा


3
Tools.ietf.org/html/rfc7231#section-6.3.1 पढ़ने के बाद , मैं इस समझ से सहमत हूं - मुझे लगता है कि मैं मोरेसो से पूछ रहा था कि आप इस पर कैसे पहुंचे। लेकिन अब मेरी समझ में ... 200 = संसाधन बनाया और लौटा | 201 = संसाधन बनाया और संदर्भ लौटाया गया है | 204 = संसाधन बनाया और कोई पेलोड वापस नहीं आया
सूदो आत्मा

34

HTTP की जाँच करें : विधि परिभाषाएँ: POST

POST विधि द्वारा की गई कार्रवाई के परिणामस्वरूप एक संसाधन नहीं हो सकता है जिसे URI द्वारा पहचाना जा सकता है। इस मामले में, 200 (ओके) या 204 (कोई सामग्री) उपयुक्त प्रतिक्रिया की स्थिति है, इस पर निर्भर करता है कि प्रतिक्रिया में एक इकाई शामिल है जो परिणाम का वर्णन करती है।

यदि मूल सर्वर पर एक संसाधन बनाया गया है, तो प्रतिक्रिया SHOULD 201 (बनाई गई) होनी चाहिए और इसमें एक इकाई शामिल होगी जो अनुरोध की स्थिति का वर्णन करती है और नए संसाधन को संदर्भित करती है, और एक स्थान हेडर (अनुभाग 14.30 देखें)।


18

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19

यह सिर्फ एक कोलोन सीमांकित कुंजी-मूल्य है।

ETag: "xyzzy"

यह किसी भी प्रकार का पाठ डेटा हो सकता है - मैं आम तौर पर बनाए गए आइटम के पहचानकर्ता के साथ एक JSON स्ट्रिंग शामिल करता हूं। अकेले परीक्षण की आसानी इसे सार्थक बनाती है।

ETag: "{ id: 1234, uri: 'http://domain.com/comments/1234', type: 'comment' }"

इस उदाहरण में, पहचानकर्ता, यूरी, और निर्मित आइटम का प्रकार "संसाधन विशेषताओं और स्थान" हैं।


3
आप कह रहे हैं कि ETag संसाधन विशेषताओं और स्थान (नों) की सूची वाली इकाई से मेल खाती है । मैं देख सकता हूं कि आपका सुझाव अच्छा है, परीक्षण के बारे में आपकी बात से बहुत सहमत हैं। हालाँकि मैं यह नहीं देखता कि यह "संसाधन विशेषताओं और स्थानों की सूची" के साथ कैसे फिट बैठता है।
djna

"संसाधन विशेषताओं और स्थानों की सूची" जो कुछ भी डेटा संरचना प्रदान करता है, उसकी सामग्री होगी। JSON संरचना के लिए संसाधन uri और शायद उस प्रकार के संसाधन को शामिल करने के लिए एक अधिक सख्त कार्यान्वयन होगा। मैं उत्तर को इस तरह समायोजित करूँगा।
टेम्परेरी

7
मुद्दों को निर्दिष्ट करें, ताकि लोग सीख सकें। अन्यथा, टिप्पणी सिर्फ हाथ से लहराती है।
टेम्परेरी

@SimonGibbs क्या मुद्दे हैं?
मेमोरियल

2
जबकि यह कड़ाई के अनुसार सही है, यह अत्यधिक असामान्य कार्यान्वयन विकल्प की सिफारिश करता है। इसके अलावा, यह वास्तव में पृष्ठ के शीर्ष पर सवाल का जवाब नहीं देता है (या फिर यह ETag और इकाई शब्द को मिलाकर ऐसा करता है)। 43 वोटों के साथ जवाब शायद बेहतर है।
शमौन गिब्स

1

आउटपुट वास्तव में अनुरोध की जा रही सामग्री प्रकार पर निर्भर है। हालाँकि, कम से कम आपको वह संसाधन रखना चाहिए जो स्थान में बनाया गया था। बिल्कुल पोस्ट-रीडायरेक्ट-गेट पैटर्न की तरह।

मेरे मामले में मैं इसे खाली छोड़ देता हूं जब तक कि अन्यथा अनुरोध न किया जाए। चूंकि Response.created () का उपयोग करते समय JAX-RS का व्यवहार होता है।

हालाँकि, बस ध्यान दें कि एंगुलर जैसे ब्राउजर और फ्रेमवर्क 201 का स्वतः अनुसरण नहीं करते हैं। मैंने http://www.trajano.net/2013/05/201-created-with-angular-resource/ में व्यवहार को नोट किया है


-2

इसके लिए मेरे पास एक और जवाब होगा कि आप एक व्यावहारिक दृष्टिकोण अपनाएँ और अपना REST API अनुबंध सरल रखें। मेरे मामले में मैंने जावास्क्रिप्ट या एक्सएचआर का सहारा लिए बिना चीजों को अधिक परीक्षण योग्य बनाने के लिए अपने रीस्ट एपीआई को रीलेक्ट किया, बस सरल HTML फॉर्म और लिंक।

तो ऊपर दिए गए आपके प्रश्न पर अधिक विशिष्ट होने के लिए, मैं सिर्फ रिटर्न कोड का उपयोग करूंगा 200और लौटाए गए संदेश में एक JSON संदेश है जिसे आपका एप्लिकेशन समझ सकता है। आपकी आवश्यकताओं के आधार पर इसे उस ऑब्जेक्ट की आईडी की आवश्यकता हो सकती है जिसे नया बनाया गया है ताकि वेब एप्लिकेशन किसी अन्य कॉल में डेटा प्राप्त कर सके।

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

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