पोस्टिंग से पहले पूर्वावलोकन दिखाने के लिए REST समापन बिंदु

Question

मैं एक नया वेब एप्लिकेशन डिजाइन कर रहा हूं जो REST बैकएंड और HTML + JS फ्रंटेंड द्वारा संचालित है।

एक इकाई को बदलने के लिए उस पर एक POST विधि है (चलो कॉन्फिग को कॉल करें), जिसमें एप्लिकेशन के कई तत्वों की स्थिति में कई दुष्प्रभाव हैं। मान लीजिए कि POST इस प्रकार किया जाता है:

POST /api/config BODY {config: ....}

इसके कारण, मैं उन परिवर्तनों को करने से पहले एक पूर्वावलोकन दिखाना चाहूंगा, अंत उपयोगकर्ता के लिए यह नोटिस करने में सक्षम होना चाहिए कि क्या बदलाव होने जा रहा है।

जिस चीज के बारे में मैंने पहली बार सोचा था , वह प्रीव्यू के लिए एक GET एंडपॉइंट बनाना है , जो नई इकाई के शरीर को भेज रहा है। इस तरफ:

GET /api/preview/items BODY {config: ....}

नए कॉन्फ़िगरेशन के साथ आइटम के लिए नई स्थिति दिखा सकते हैं।

GET /api/preview/sales BODY {config: ....}

नए कॉन्फ़िगरेशन के साथ बिक्री के लिए नया राज्य दिखा सकता है।

GET क्रिया का उपयोग करना एक अच्छा विचार है क्योंकि मैं एप्लिकेशन की स्थिति में परिवर्तन नहीं कर रहा हूं। हालाँकि, GET अनुरोधों के साथ एक अनुरोध निकाय का उपयोग हतोत्साहित किया जा रहा है ।

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

POST /api/preview/config BODY {config: ....}

GET /api/preview/items?idPreviewConfig=1

Comments

क्या वास्तव में यह विन्यास हो सकता है और यह कैसे प्रभावित करता है itemsया sales? क्या यह लौटी इकाई के प्रतिनिधित्व को प्रभावित करता है?

— एंडी

मान लीजिए कि आपके द्वारा कॉन्फ़िगरेशन में किए गए परिवर्तनों से आइटम और बिक्री दोनों प्रभावित होते हैं।

— Xtreme बाइकर

लेकिन बदलावों का क्या मतलब है? क्या यह लौटी संस्थाओं के सेट को बदलता है? क्या यह लौटी हुई संरचना को बदलता है?

— एंडी

वास्तव में यह आपके द्वारा पोस्ट किए गए कॉन्फ़िगरेशन के आधार पर itemsऔर sales(नहीं) संरचना के लिए मूल्यों को बदलता है ।

— Xtreme बाइकर

और विन्यास कितना बड़ा है? कई सौ किलोबाइट तक बढ़ सकता है या इससे भी अधिक?

— एंडी

Answer 1

यह HTTP में मूल समर्थन के लिए बहुत अधिक डोमेन-विशिष्ट है।

इसके बजाय, आप निम्न में से एक कर सकते हैं:

1. ए है POST /api/config/preview। सर्वर साइड पर, एप्लिकेशन को पता चल जाएगा कि उसे वास्तविक कॉन्फ़िगरेशन को संशोधित नहीं करना चाहिए, लेकिन वास्तविक एक को आपके द्वारा पोस्ट किए गए के साथ जोड़ दें, और जो परिणाम बदला गया था उसे इंगित करते हुए परिणाम लौटाएं।

   बाद में, यदि उपयोगकर्ता परिणाम से संतुष्ट है, तो वह POST /api/configपिछले अनुरोध के अनुसार एक ही पेलोड करेगा । यह प्रभावी रूप से कॉन्फ़िगरेशन को अधिलेखित कर देगा।

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

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

2. एक POST /api/config/prepareयाद रखें जो अस्थायी रिकॉर्ड में भेजा गया था और दो चीजें लौटाता है: अस्थायी रिकॉर्ड की आईडी (उदाहरण के लिए 12345) और परिवर्तनों का पूर्वावलोकन।

   यदि उपयोगकर्ता परिणाम से संतुष्ट है, तो वह POST /api/config/commit/12345निश्चित रूप से परिवर्तनों को संग्रहीत करने के लिए प्रदर्शन करेगा । यदि नहीं, तो अस्थायी रिकॉर्ड को कुछ समय के लिए रखा जा सकता है, और फिर एक क्रॉन नौकरी द्वारा छोड़ दिया जाता है।

   लाभ यह है कि, यहां आप फिर से मूल POST /api/configबरकरार रख सकते हैं , और जिन ग्राहकों को पूर्वावलोकन की आवश्यकता नहीं है, वे नहीं टूटेंगे।

   कमियां यह हैं कि (1) अस्थायी रिकॉर्ड को हटाने का काम मुश्किल हो सकता है (क्या आपको लगता है कि एक घंटे के लिए पर्याप्त है? क्या होगा अगर दस मिनट बाद, आप स्मृति से बाहर चले जाते हैं? क्लाइंट एक HTTP 404 को कमिट करते समय कैसे संभालते हैं? एक रिकॉर्ड जो समाप्त हो गया है?) और वह (2) रिकॉर्ड के दो-चरण प्रस्तुत करने की तुलना में अधिक जटिल हो सकता है।

3. ग्राहक पक्ष पर पूर्वावलोकन तर्क को स्थानांतरित करें।

Comments

एक हेडर भेजने के बारे में क्या कहता है कि "यह जारी नहीं है, केवल मुझे क्या-अगर दिखाओ"? मैं संपादित करेंगे कि इसका जवाब में यदि आप के साथ ठीक thats @ArseniMourzenko

— marstato

@marstato: व्यक्तिगत रूप से, मैं उस उपयोग के लिए विशेष रूप से HTTP हेडर का शौकीन नहीं हूं। यद्यपि यह अन्य लोगों के लिए समझ में आता है, इसलिए यदि आप मेरा उत्तर संपादित करते हैं तो मैं ठीक हूँ। ध्यान दें कि आप अपना स्वयं का उत्तर भी पोस्ट कर सकते हैं, जो दूसरों को इसे बढ़ाने की अनुमति देगा (और आपको प्रतिष्ठा अंक प्राप्त करेगा)।

— Arseni Mourzenko

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

— Xtreme बाइकर

@PedroWerneck क्या आप उस पर विस्तार कर सकते हैं? यह मुझे लगता है कि विकल्प 2 एक अन्य इकाई (ड्राफ्ट कॉन्फिगर) को परिभाषित करता है और उनके साथ बातचीत करने के लिए स्टेटलेस तरीके प्रदान करता है।

— एंड्रयू

@PedroWerneck यह उसी तरह से स्टेटस है जिस तरह से सर्वर पर कॉन्फिगर करना स्टेटफुल है। इसलिए एप्लिकेशन आपके दृष्टिकोण से पहले से ही स्टेटफुल है और इसलिए इस सुविधा को जोड़ने के लिए सभी विकल्प हैं।

— jpmc26

Answer 2

REST में विभिन्न एपीआई कॉल के लिए विशिष्ट HTTP क्रियाओं का उपयोग करने का उद्देश्य मौजूदा HTTP यांत्रिकी और अपेक्षाओं का लाभ उठाना है।

इस मामले में GET का उपयोग करना दोनों के खिलाफ जाना प्रतीत होता है।

A. ग्राहक को GET के साथ एक निकाय शामिल करना होगा? अप्रत्याशित

बी। सर्वर शरीर के आधार पर एक अलग प्रतिक्रिया देता है? कल्पना और कैशिंग यांत्रिकी को तोड़ता है

यदि आप Restful सवालों से जूझ रहे हैं, तो मेरा नियम खुद से पूछना है।

"यह सब कुछ के लिए केवल POST का उपयोग करने से बेहतर कैसे है?"

जब तक कोई तात्कालिक और स्पष्ट लाभ न हो, तब तक जस्ट यूज़ पोस्ट स्टूपिड (JUPS) रणनीति के साथ जाएं

Comments

Hahaha अच्छा पकड़

— Xtreme बाइकर

@ इवान ... भले ही यह एक व्यावहारिक दृष्टिकोण है या नहीं ... अगर आप हर चीज के लिए POST का उपयोग कर रहे हैं तो यह ध्यान दिया जाना चाहिए कि यह वास्तव में RESTful नहीं है।

— एलनफ

जब तक, POST आपके सभी तरीकों के लिए उपयुक्त विकल्प नहीं है। और ऐसा नहीं है कि एक उद्देश्य नियम है जिसे आप लागू कर सकते हैं, हम बस हमारे व्यक्तिपरक व्याख्याओं पर बहस कर रहे होंगे जो एक दिशानिर्देश से थोड़ा अधिक है।

— इवान

Answer 3

आप एक हेडर भेज सकते हैं जो सर्वर को इंगित करता है "इसे जारी न रखें, केवल मुझे दिखाएं कि यदि आपने किया तो परिणाम क्या होगा"। उदाहरण के लिए

POST /api/config HTTP/1.1
Host: api.mysite.com
Content-Type: application/json
Persistence-Options: simulate

{
   "config": {
      "key": "value"
   }
}

जिस पर सर्वर प्रतिक्रिया दे सके:

HTTP/1.1 200 OK
Persistence-Options: simulated
Content-Type: application/json

-- preview --

---

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

Comments

tools.ietf.org/html/rfc6648

— पीटर रेडर

अच्छा बिंदु @PeterRader, हटायाX-

— marstato

आपका स्वागत है। क्या आप कहेंगे कि सिमुलेशन के तहत एक इकाई को "सिमुलेशन के तहत" के रूप में दर्शाया जाना चाहिए?

— पीटर रेडर

नहीं; एक सिमुलेशन की बात है, यह नहीं है? हेडर का मूल्य भी हो सकता है noneलेकिन मेरे स्वाद के लिए - POSTविधि की प्रकृति के साथ बहुत अधिक विरोधाभास होगा ।

— marstato

Answer 4

मैं सुझाव दूंगा कि आप उसी तरह से खोजें जैसे आप खोजते हैं। मैं एक POST समापन बिंदु स्थापित करूंगा /api/config/previewजिस पर एक नया पूर्वावलोकन बनाता है। फिर मैं इस api/configआधार पर एक PUT या PATCH समापन बिंदु स्थापित करूंगा कि क्या आप वर्तमान कॉन्फ़िगरेशन को संपादित करने का इरादा रखते हैं, या बस पूरे कॉन्फिग को बदलें (संभवतः पूर्व में आपके द्वारा बनाए गए पूर्वावलोकन को भेजना होगा)।

Answer 5

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

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

Answer 6

RFC6648 नए X-निर्माणों को चित्रित करता है इसलिए मुझे एक नए हेडर-फ़ील्ड भेजने के विचार के खिलाफ वोट करना होगा। REST एक वास्तुकला शैली है, जिसके बारे में हम बात करते हैं वह Restful है - लेकिन इस पल के लिए इसे अनदेखा कर देता है।

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

GET  /api/emulation - 200 OK {first:1, last:123}
POST /api/emulation/124 - 200 OK
GET  /api/emulation/124/config - 200 OK {config:{tax:8}}
PUT  /api/emulation/124/config {config:{tax:16}} - 200 OK {config:{tax:16}}
GET  /api/emulation/124/items - 200 OK [first:1, last: 3000]
GET  /api/emulation/124/items/1 - 200 OK {price:1.79, name:'Cup'}
--- show emulation ---
--- commit emulation ---
PUT /api/config {config:{tax:16}}
DELETE /api/emulation/124 - 200 OK

एक और दृष्टिकोण है .... आपने HTML / जावास्क्रिप्ट-क्लाइंट से अनुरोधों का एक बहुत कुछ देखा हो सकता है बहुत अधिक अनुरोधों का उत्पादन कर सकता है , जो एक ही समय में लगभग 17 अनुरोधों की सीमा तक पहुँचता है ( इस पृष्ठ पर एक नज़र डालें )। आप REST के उपयोग की अदला-बदली कर सकते हैं और इसके बजाय लंगड़ा वस्तु-राज्यों को वितरित करके आप समृद्ध उपयोगकर्ता-विशिष्ट पृष्ठ-राज्य दे सकते हैं। उदाहरण:

GET /user/123/config - 200 OK {user:'Tim', date:3298347239847, currentItem:123, 
                  roles:['Admin','Customer'], config:{tax:16}, unsavedChanges:true, ...}

सधन्यवाद