गैर-CRUD संचालन को संभालने के लिए REST API कैसे डिज़ाइन करें?

Question

मैं SOAP- आधारित सेवाओं के एक सेट को RESTful API में बदलने की कोशिश कर रहा हूं।

मैंने ऑपरेशन नामों का विश्लेषण करके संसाधनों की पहचान करना शुरू किया और मुझे संसाधन मिल गए Subscription।

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

इन मामलों में, अंतर्निहित संचालन को संभालने के लिए सबसे अच्छा अभ्यास क्या है?

मैं जिस समाधान के साथ आया था वह क्वेरी मापदंडों का उपयोग करना है, ताकि अगर मुझे सक्रियण सेवा को कॉल करने की आवश्यकता हो, तो मैं कुछ का उपयोग कर सकता हूं:

POST /subscriptions/{subscriptionid}/?activate=true

यह देखते हुए कि मैं सीधे अपनी सदस्यता वस्तु क्षेत्रों को अपडेट नहीं कर सकता, क्या इस तरह के रूपांतरण को संभालने के लिए कोई सर्वोत्तम अभ्यास है?

अपडेट 1:

मैं अपने POST के शरीर में कुछ मान रख सकता हूं, उदाहरण के लिए "राज्य": "सक्रिय"

और मेरी सेवा के अंदर जांच करें कि उचित संचालन चालू हो।

Comments

HTTP क्रियाओं के लिए आदेशों की मैपिंग जटिल ऑपरेशन के साथ विफल हो जाती है। आप आरपीसी स्टाइल कॉल POST सक्रिय करें / {आईडी} से बेहतर कर रहे हैं, कोई भी इसे भ्रमित नहीं करेगा

— इवान

@ मुझे यकीन नहीं है कि यह Restful मॉडल का अनुपालन करता है, लेकिन मैं एक और समाधान के साथ आया हूं: अपने कोड में मैं इनपुट पेलोड के अनुसार उचित RPC- शैली ऑपरेशन को कॉल कर सकता हूं (मैं राज्य को पास कर सकता हूं = शरीर में सक्रिय मेरा पोस्ट अनुरोध, कोड सक्रियण कोड को कॉल करेगा)

— Vektor88

मौजूदा संसाधन जैसे कि एक PATCH का अपडेट होना चाहिए, और क्वेरी का निकाय तब जो आप बदल रहे हैं उसका एक आंशिक मॉडल है। POST एक ऐसा अनुरोध माना जाता है जो एक संसाधन बनाता है। यह अंतर उपयोगकर्ता के लिए स्पष्ट होने के अलावा, आपके कोड को यह जानने में आसान बना देगा कि यह ऑपरेशन संसाधन पोस्ट के बजाय कब हो रहा है।

— श्री कोच

@ Vektor88 आमतौर पर, लेकिन वे बेकार ऑपरेशन हैं जहां आपको पूरे संसाधन राज्य प्रतिनिधित्व में पास करने की आवश्यकता होती है। यह उपयोग मामला आंशिक अद्यतन की तरह कहीं अधिक लगता है, जो वास्तव में एक अच्छी तरह से फिट बैठता है।

— श्री कोच

@MrCochese POST बेकार नहीं है।

— जिमीजैम

Answer 1

आपको जिम वेबर की इस बात को देखना होगा ।

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

"संदेश" सोचो; अपने डोमेन को एक संदेश भेजें, यह वर्णन करते हुए कि आप क्या करना चाहते हैं। संदेश का साइड इफेक्ट यह है कि आपका डोमेन मॉडल वास्तव में अपनी स्थिति बदल देता है। "संसाधन" संदेश कतार है।

POST /subscriptions/{subscriptionid}/?activate=true

संसाधन नाम की वर्तनी मशीनों के लिए कोई मायने नहीं रखती है; लेकिन लोग तब उधम मचाते हैं, जब आपके द्वारा उपयोग किए जाने वाले पहचानकर्ताओं को इस संधि से तोड़ दिया जाता है कि संसाधन "संज्ञाएं" हैं।

साथ ही, हम एक ऐसे संसाधन के बारे में बात कर रहे हैं, जो इस संबंध को क्वेरी भाग का उपयोग करने के बजाय एक पथ खंड के साथ उस संबंध को व्यक्त करने के लिए है /subscriptions/{subscriptionid}( RFC 3986 देखें ) सम्मेलन ।

तो ये वर्तनी उचित हो सकती है

POST /subscriptions/{subscriptionid}/messages
POST /subscriptions/{subscriptionid}/activations

Comments

जिम वेबर की बातचीत youtube.com/watch?v=aQVSzMV8DWc

— user674669

Answer 2

यदि सामान को सक्रिय / निष्क्रिय करने के लिए इसका बूलियन ध्वज है, तो मैं कहूंगा कि डिफ़ॉल्ट JSON का उपयोग करना है:

POST /subscriptions/{subscriptionid}/
{
    format: 0,
    subscription: 
    {
        active: false
    }
}

यदि आप अधिक गुणों का समर्थन करना चाहते हैं तो यह आसानी से विस्तारित है। एक और दृष्टिकोण इसे अपना समापन बिंदु दे रहा है:

POST /subscriptions/{subscriptionid}/active/
DELETE /subscriptions/{subscriptionid}/active/

व्यक्तिगत रूप से, मैं इसका उपयोग केवल तभी करूंगा जब activeइस घटना की स्थिति में ऐसे गुण हों, जिन्हें आप तब उपयोगकर्ता आईडी या सेटिंग की तरह JSON में पास / प्राप्त कर सकते हैं।

यदि इसकी बूलियन वैल्यू नहीं है, लेकिन सिर्फ एक एक्शन है जिसे आपको ट्रिगर करने की आवश्यकता है, लेकिन इसके लिए किसी स्टेटस फीडबैक की आवश्यकता नहीं है / (तत्काल 200 ओके को छोड़कर), तो मैं इसे आरपीसी की तरह ट्रिगर करने के लिए इस तरह एक एंडपॉइंट का उपयोग करूंगा:

POST /subscriptions/{subscriptionid}/activate/

जब संदेह हो, तो इसे पढ़ें: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#restful (देखें "उन कार्यों के बारे में जो CRUD ऑपरेशन की दुनिया में फिट नहीं होते हैं?" ")

Answer 3

REST गैर-कार्यात्मक है। Activateएक क्रिया है और एक अवस्था नहीं हो सकती है, Activeएक अवस्था है।

Restful गैर-कार्यात्मक होने के कारण आप RESTful सेवा को नहीं बता सकते कि क्या करना है, लेकिन आप किसी सेवा की कतार के लिए काम जोड़ सकते हैं।

यह देखो:

PUT /subscriptionQueue
subscriptionId={subscriptionId}
active=true

यह अनुरोध RESTful है और RESTful के सभी लाभों (जैसे प्रदर्शन, एसिड ...) का समर्थन करता है