आरईएसटी एपीआई प्रति संसाधन

Question

के साथ कई आदेशों के साथ आरईएसटी एपीआई डिजाइन के बारे में मेरा कोई प्रश्न है। यहां एक साधारण (शायद बहुत आसान) एपीआई है:

GET /ecommerce/order/123 

POST /ecommerce/order (create a new order) 

PUT /ecommerce/order/123 (update an existing order) 

DELETE /ecommerce/order/123 (cancel order) 

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

एक अन्य समाधान एपीआई बदलने के लिए होगा:

GET /ecommerce/order/123 

POST /ecommerce/order/create (create a new order) 

PUT /ecommerce/order/update/123 (update an existing order) 

DELETE /ecommerce/order/cancel/123 (cancel order) 

मुझे यकीन है कि जो सबसे अच्छा विकल्प है नहीं कर रहा हूँ।

एक और सामान्य सवाल है कि आरईएसटी एपीआई एक संसाधन के लिए एकाधिक कमांड कैसे संभालता है।

किसी भी इनपुट की सराहना की जाएगी! मैं जल्द ही अभ्यास में रीस्ट पढ़ रहा हूं लेकिन यह सवाल मुझ पर घूम रहा है।

Answer 1

एक विकल्प एक नया संसाधन बनाना हो सकता है। CancelledOrder, शायद।

आप हो सकता है तो POST एक नया CancelledOrder:

POST /ecommerce/cancelledOrder 
Entity: 
    order: /ecommerce/order/123 
    reason: "Problem with order" 

तुम भी/बजाय PUT एक CancelledOrder सकता है:

PUT /ecommerce/cancelledOrder/123 
Entity: 
    reason "Problem with order" 

आवेदन तो आदेश 123 हटा सकते हैं या इसकी स्थिति अपडेट कर सकता है "रद्द" करने के लिए , या जो कुछ भी आपके व्यवसाय नियमों की आवश्यकता है वह करें। इसे ऊपर करने के लिए, आप DELETE विधि को /ecommerce/order/N के लिए सीधे 405 Method Not Allowed पर वापस करने का समर्थन नहीं कर सकते।

PUT समाधान अपने लाभ के लिए बेवकूफता का उपयोग कर सकते हैं; PUTCancelledOrder टिंग कई बार हमेशा आदेश रद्द होने के परिणामस्वरूप होगा।

यह ध्यान दिया जाना चाहिए कि एपीआई बदलने के लिए आपके सुझाव (उदा। /ecommerce/order/create) संभवतः संसाधन पहचानकर्ताओं में विधियों को परिभाषित करने के बाद से विश्वसनीय नहीं होने की संभावना है।

Answer 2

(सवाल काफी पुराना है, लेकिन मैं तो बस सोचा था कि मैं इसे सुधारने चाहते हैं, के रूप में मैं किसी भी समाधान वहाँ पसंद नहीं है।)

समाधान सरल है। अनुरोध के शरीर में एक कारण रखो।

DELETE /ecommerce/order/123 
Content-Type: text/plain 
Content-Length: 48 

Order was cancelled due to a customer's request. 

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

मेरी राय में यह जावास्पेक आरपीसी की तरह OrderCancellator.execute(order) (क्योंकि POST "execute" के लिए HTTP का नाम है) से बेहतर तरीका है।

सावधान रहें, जबकि spec इसके बारे में कुछ नहीं कहता है, कुछ may discard DELETE request's body को अलग करता है।draft on HTTP/1.1 message semantics स्पष्ट करता है:

DELETE अनुरोधों पर निकायों में कोई परिभाषित अर्थशास्त्र नहीं है। ध्यान दें कि किसी DELETE अनुरोध पर निकाय भेजने से अनुरोध को अस्वीकार करने के लिए कुछ मौजूदा कार्यान्वयन हो सकते हैं।

DELETE /ecommerce/order/123 
X-Reason: Cancelled due to an UFO invasion. 

जब भी हेडर चुनने के लिए या संस्था शरीर के आकार और डाटा का स्वरूप पर निर्भर करता है:

एक अन्य विकल्प एक हैडर जारी करने के लिए है। कुछ डेटा HTTP हेडर में ठीक फिट बैठता है, कुछ नहीं करता है। एक निश्चित रूप से संख्यात्मक टिकट आईडी पास कर सकता है, यह तारों के बारे में अनिश्चित है (यूनिकोड सोचें) और यह निश्चित है कि उनके सचेत मन में कोई भी बेस 64 जेपीईजी पास नहीं करना चाहता है।

Answer 3

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

पोस्ट/ई-कॉमर्स/आदेश/123/

रद्द कौन सा मौजूदा संसाधन पर विभिन्न संचालन को संभालने का एक सामान्य तरीका है। मुझे नहीं लगता कि आदेश रद्द करने से ऑर्डर को हटाने का कारण क्यों कम से कम नहीं होगा। उपयोगकर्ता शायद सिस्टम में ऑर्डर देखना चाहते हैं। ऑर्डर भी है जहां आप रद्दीकरण के कारण को स्टोर करेंगे।