अन्य एपीआई अवधारणाओं

Question

REST API डिज़ाइन के बारे में मेरे तीन प्रश्न हैं जो मैं उम्मीद कर रहा हूँ कि कोई व्यक्ति कुछ प्रकाश डाल सकता है। मैंने कई घंटों तक अथक खोज की है, लेकिन मुझे कहीं भी अपने सवालों के जवाब नहीं मिले हैं (हो सकता है कि मुझे अभी पता नहीं है कि क्या खोजा जाए?)।

प्रश्न 1

मेरा पहला सवाल कार्रवाई / आरपीसी के साथ करना है। मैं थोड़ी देर के लिए REST API विकसित कर रहा हूं और मैं संग्रह और संसाधनों के संदर्भ में चीजों के बारे में सोच रहा हूं। हालाँकि, मैं ऐसे कुछ मामलों में आया हूँ जहाँ प्रतिमान लागू नहीं होता है और मुझे आश्चर्य हो रहा है कि क्या इस तरह के प्रतिमान के साथ सामंजस्य स्थापित करने का कोई तरीका है।

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

क्या किसी संसाधन URI (जैसे /collection/123?action=resendEmail) के साथ किसी प्रकार की कार्रवाई कॉल को मिलाना उचित है ? क्या कार्रवाई को निर्दिष्ट करना और इसके लिए संसाधन आईडी पास करना बेहतर होगा (जैसे /collection/resendEmail?id=123)? क्या यह इसके बारे में गलत तरीका है? परंपरागत रूप से (कम से कम HTTP के साथ) किया जा रहा कार्य अनुरोध विधि (GET, POST, PUT, DELETE) है, लेकिन वे वास्तव में किसी संसाधन के साथ कस्टम क्रियाओं की अनुमति नहीं देते हैं।

प्रश्न 2

मैं संग्रह का संग्रह करते समय लौटे संसाधनों के सेट को फ़िल्टर करने के लिए URL के क्वेरिस्ट्रिंग भाग का उपयोग करता हूं /collection?someField=someval। मेरे एपीआई नियंत्रक के भीतर मैं फिर यह निर्धारित करता हूं कि उस क्षेत्र और मूल्य के साथ यह किस तरह की तुलना करने जा रहा है। मैंने पाया है कि यह वास्तव में काम नहीं करता है। मुझे एपीआई उपयोगकर्ता को उस तरह के तुलना को निर्दिष्ट करने की अनुमति देने का एक तरीका चाहिए जो वे प्रदर्शन करना चाहते हैं।

सबसे अच्छा विचार मैं अब तक लेकर आए हैं एपीआई उपयोगकर्ता फ़ील्ड नाम के लिए एक उपांग (जैसे के रूप में यह निर्दिष्ट करने के लिए अनुमति देने के लिए है /collection?someField:gte=someval- संकेत मिलता है कि यह संसाधनों लौटना चाहिए जहां someFieldसे बड़ी है या के बराबर (> =) जो कुछ भी somevalहै क्या यह एक अच्छा विचार है? एक बुरा विचार? यदि हां, तो क्यों? उपयोगकर्ता को दिए गए क्षेत्र और मूल्य के साथ तुलना करने के लिए तुलना के प्रकार को निर्दिष्ट करने की अनुमति देने का एक बेहतर तरीका है?

प्रश्न 3

मैं अक्सर यूआरआई देखता हूं कि कुछ ऐसा है जैसे एस /person/123/dogsप्राप्त करना । मैंने आमतौर पर ऐसा कुछ टाला है क्योंकि अंत में मुझे लगता है कि इस तरह से एक यूआरआई बनाने से आप वास्तव में एक विशिष्ट आईडी द्वारा फ़िल्टर किए गए संग्रह तक पहुंच सकते हैं । इसके बराबर होगा । क्या वास्तव में एक REST URI के दो स्तरों से अधिक गहरे ( ) होने का एक अच्छा कारण है ?persondogsdogsperson/dogs?person=123/collection/resource_id

Comments

आपके तीन सवाल हैं। उन्हें अलग से पोस्ट क्यों नहीं किया गया?

— अनएक्सिमैंडर

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

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

— एंड्रयू टी फिननेल

बेहतर हो सकता है कि उन्हें अलग से पोस्ट करें, IDK। हालाँकि, जैसा कि @AndrewFinnell ने उल्लेख किया है, मुझे लगा कि प्रश्नों को एक साथ रखना एक अच्छा विचार होगा क्योंकि ये सबसे कठिन REST संबंधित प्रश्न हैं जो मैंने लिए हैं और अन्य लोगों के लिए उत्तर खोजने में सक्षम होना अच्छा होगा। साथ में।

— जस्टिन वॉर्केंटिन

Answer 1

क्या किसी संसाधन URI (जैसे /collection/123?action=resendEmail) के साथ किसी प्रकार की कार्रवाई कॉल को मिलाना उचित है ? क्या कार्रवाई को निर्दिष्ट करना और इसके लिए संसाधन आईडी पास करना बेहतर होगा (जैसे /collection/resendEmail?id=123)? क्या यह इसके बारे में गलत तरीका है? परंपरागत रूप से (कम से कम HTTP के साथ) किया जा रहा कार्य अनुरोध विधि (GET, POST, PUT, DELETE) है, लेकिन वे वास्तव में किसी संसाधन के साथ कस्टम क्रियाओं की अनुमति नहीं देते हैं।

मैं इसके बजाय एक अलग तरीके से मॉडल बनाना चाहता हूं, जो भेजे जाने वाले ईमेल का प्रतिनिधित्व करने वाले संसाधनों का एक संग्रह है; भेजने की प्रक्रिया नियत समय पर सेवा के आंतरिक लोगों द्वारा संसाधित की जाएगी, जिस बिंदु पर संबंधित संसाधन हटा दिया जाएगा। (या उपयोगकर्ता संसाधन को जल्द से जल्द हटा सकता है, जिससे भेजने का अनुरोध रद्द कर दिया जाएगा।)

आप जो कुछ भी करते हैं, संसाधन नाम में क्रिया नहीं करते हैं! यह संज्ञा है (और क्वेरी भाग विशेषणों का समूह है)। Nouning verbs रेयर वुड्स!

मैं संग्रह का संग्रह करते समय लौटे संसाधनों के सेट को फ़िल्टर करने के लिए URL के क्वेरिस्ट्रिंग भाग का उपयोग करता हूं /collection?someField=someval। मेरे एपीआई नियंत्रक के भीतर मैं फिर यह निर्धारित करता हूं कि उस क्षेत्र और मूल्य के साथ यह किस तरह की तुलना करने जा रहा है। मैंने पाया है कि यह वास्तव में काम नहीं करता है। मुझे एपीआई उपयोगकर्ता को उस तरह के तुलना को निर्दिष्ट करने की अनुमति देने का एक तरीका चाहिए जो वे प्रदर्शन करना चाहते हैं।

अब तक जो सबसे अच्छा विचार आया है, वह यह है कि एपीआई उपयोगकर्ता को फ़ील्ड नाम के उपांग के रूप में इसे निर्दिष्ट करने की अनुमति दी जाए (जैसे /collection?someField:gte=someval- यह इंगित करने के लिए कि उसे संसाधनों को वापस करना चाहिए जहां someField इससे अधिक या उसके बराबर ( >=) somevalहै। क्या यह एक अच्छा विचार है? एक बुरा विचार? यदि हां, तो क्यों? उपयोगकर्ता को दिए गए क्षेत्र और मूल्य के साथ तुलना करने के लिए तुलना के प्रकार को निर्दिष्ट करने की अनुमति देने का एक बेहतर तरीका है?

मैं सामान्य फ़िल्टर क्लॉज़ निर्दिष्ट करना चाहता हूं और संग्रह की सामग्री लाने के लिए किसी भी अनुरोध पर एक वैकल्पिक क्वेरी पैरामीटर के रूप में है। क्लाइंट तब निर्दिष्ट कर सकता है कि आप जिस भी तरह से चाहें, वापस लौटाए गए सेट को प्रतिबंधित करें। मुझे फ़िल्टर / क्वेरी भाषा की खोज के बारे में भी थोड़ी चिंता होगी; अमीर आप इसे बनाते हैं, यह कठिन है कि मनमाने ग्राहकों के लिए खोज की जाए। एक वैकल्पिक दृष्टिकोण, जो कम से कम सैद्धांतिक रूप से, उस खोजनीयता के मुद्दे से संबंधित है, जो संग्रह के प्रतिबंध उप-संसाधनों को बनाने की अनुमति देता है, जो ग्राहकों को संग्रह संसाधन के प्रतिबंध का वर्णन करते हुए एक दस्तावेज़ को पोस्ट करके प्राप्त होता है। यह अभी भी एक मामूली दुरुपयोग है, लेकिन कम से कम यह एक है जिसे आप स्पष्ट रूप से खोज कर सकते हैं!

इस प्रकार की खोजशीलता उन चीजों में से एक है जो मुझे REST के साथ कम से कम मजबूत लगती है।

मैं अक्सर यूआरआई देखता हूं कि कुछ ऐसे दिखते हैं जैसे /person/123/dogsव्यक्तियों को कुत्ते मिलते हैं। मैं आमतौर पर ऐसा कुछ करने से बचता हूं क्योंकि अंत में मुझे लगता है कि इस तरह से एक यूआरआई बनाने से आप वास्तव में एक विशिष्ट व्यक्ति आईडी द्वारा फ़िल्टर किए गए कुत्तों के संग्रह तक पहुंच सकते हैं। इसके बराबर होगा /dogs?person=123। क्या वास्तव में एक REST URI के दो स्तरों से अधिक गहरे ( /collection/resource_id) होने का एक अच्छा कारण है ?

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

अन्य प्रकार के संग्रह को HTTP रीडायरेक्ट के रूप में तैयार किया जा सकता है; इस प्रकार /person/123/dogsवास्तव में एक 307 करने से जवाब दिया जा सकता है जो करने के लिए पुनर्निर्देशित करता है /dogs?person=123। इस मामले में, संग्रह वास्तव में यूएमएल रचना नहीं है, बल्कि यूएमएल एकत्रीकरण है। फर्क मायने रखता है; यह महत्वपूर्ण है!

Comments

आपके पास कुल मिलाकर ठोस बिंदु हैं। हालांकि, जबकि resendEmailएक संग्रह बनाकर और इसे पोस्ट करने से कार्रवाई को नियंत्रित किया जा सकता है, यह कम स्वाभाविक लगता है। मैं वास्तव में, डेटाबेस में कुछ भी संग्रहीत नहीं करता हूं जब एक ईमेल नाराज है (कोई ज़रूरत नहीं)। किसी भी संसाधन को संशोधित नहीं किया गया है, इस प्रकार यह केवल एक क्रिया है जो या तो सफल होती है या विफल। मैं एक रिसोर्स आईडी नहीं दे सकता जो कॉल के जीवन से परे मौजूद है, इस तरह के कार्यान्वयन को RESTful होने के बजाय एक हैक बना देता है। यह बस एक CRUD ऑपरेशन नहीं है।

— जस्टिन वॉर्केंटिन

Answer 2

यह समझने में थोड़ा उलझन में है कि मैंने उन सभी तरीकों के आधार पर REST का ठीक से उपयोग कैसे किया है जो मैंने बड़ी कंपनियों को अपने REST API को डिज़ाइन करते हुए देखा है।

आप सही हैं कि REST एक संसाधन संग्रह प्रणाली है। यह प्रतिनिधि राज्य हस्तांतरण के लिए खड़ा है। अगर आप मुझसे पूछें तो कोई बड़ी परिभाषा नहीं। लेकिन मुख्य अवधारणाएं 4 HTTP वर्ब हैं और स्टेटलेस हैं।

ध्यान देने वाली महत्वपूर्ण बात यह है कि आपके पास REST के साथ केवल 4 VERBS हैं। ये GET, POST, PUT और DELETE हैं। आपका resendउदाहरण रीस्ट में एक नया वर्ब जोड़ना होगा। यह लाल झंडा होना चाहिए।

प्रश्न 1

यह महसूस करना महत्वपूर्ण है कि आपके REST API के कॉलर को यह पता नहीं होना चाहिए कि PUTआपके संग्रह पर प्रदर्शन करने से ई-मेल उत्पन्न होगा। मेरे लिए एक रिसाव की बू आ रही है। वे जो जान सकते थे, वह यह है कि PUTअतिरिक्त कार्य करने के परिणामस्वरूप जो वे बाद में क्वेरी कर सकते थे। उन्हें GETहाल ही में बनाए गए संसाधन पर प्रदर्शन करके यह पता चलेगा । यह GETसंसाधन को लौटाएगा और Taskसंसाधन आईडी के सभी इसके साथ जुड़े होंगे। आप बाद में उन कार्यों को उनकी स्थिति निर्धारित करने के लिए क्वेरी कर सकते हैं और एक नया सबमिट भी कर सकते हैं Task।

आपके पास कुछ विकल्प हैं।

REST - कार्य संसाधन आधारित दृष्टिकोण

एक tasksसंसाधन बनाएँ जिसमें आप कार्य करने के लिए अपने सिस्टम में विशिष्ट कार्य प्रस्तुत कर सकें। फिर आप GETइस पर आधारित कार्य को IDयह निर्धारित करने के लिए लौटा सकते हैं कि यह स्थिति है।

या आप SOAP over HTTPअपने आर्किटेक्चर में कुछ आरपीसी जोड़ने के लिए एक वेब सेवा में मिश्रण कर सकते हैं ।

किसी विशिष्ट संसाधन के लिए सभी कार्यों के लिए क्वेरी करना

GET http://server/api/myCollection/123/tasks

{ "tasks" :
    [ { "22333" : "http://server/api/tasks/223333" } ] 
}

कार्य संसाधन उदाहरण

PUT http://server/api/tasks

{ 
    "type" : "send-email" , 
    "parameters" : 
    { 
         "collection-type" : "foo" , 
         "collection-id" : "123" 
    } 
}

==> कार्य का आईडी लौटाता है

223334

GET http://server/api/tasks/223334

{ 
    "status" : "complete" , 
    "date" : "whenever" 
}

REST- क्रियाओं को ट्रिगर करने के लिए POST का उपयोग करना

आप हमेशा POSTकिसी संसाधन के लिए अतिरिक्त डेटा ले सकते हैं । मेरी राय में यह REST की भावना का उल्लंघन होगा लेकिन यह अभी भी अनुपालन होगा।

आप इसके समान एक POST कर सकते हैं:

POST http://server/api/collection/123

{ "action" : "send-email" }

आप अतिरिक्त डेटा के साथ संग्रह से संसाधन 123 को अद्यतन कर रहे होंगे। वह अतिरिक्त डेटा अनिवार्य रूप से एक क्रिया है जो बैकएंड को उस संसाधन के लिए एक ईमेल भेजने के लिए कहती है।

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

SOAP - वेब सेवा जो REST से प्राप्त संसाधनों को स्वीकार करती है

एक नया WebService बनाएं जिसमें आप REST API से पिछली संसाधन आईडी के आधार पर ई-मेल भेज सकते हैं। मैं यहाँ SOAP के बारे में विस्तार से नहीं जाऊँगा क्योंकि मूल प्रश्न REST के बारे में है और इन दोनों अवधारणाओं / तकनीकों की तुलना सेब और संतरे के रूप में नहीं की जानी चाहिए ।

प्रश्न 2

आपके पास यहां कुछ विकल्प भी हैं:

यह कई बड़ी कंपनियों को प्रकट करता है जो REST API को प्रकाशित करते हैं जो एक searchसंग्रह को उजागर करते हैं जो संसाधनों को वापस करने के लिए क्वेरी मापदंडों में पारित करने का एक तरीका है।

GET http://server/api/search?q="type = myCollection & someField >= someval"

जो पूरी तरह से योग्य REST संसाधनों का एक संग्रह लौटाएगा जैसे:

{
    "results" : 
       { [ 
             "location" : "http://server/api/myCollection/1",
             "location" : "http://server/api/myCollection/9",
             "location" : "http://server/api/myCollection/56"
         ]
       }
}

या आप एमवीईएल जैसे कुछ को क्वेरी पैरामीटर के रूप में अनुमति दे सकते हैं ।

प्रश्न 3

मैं एक उप-स्तरों को पसंद करता हूं ताकि एक पैरामीटर को क्वेरी पैरामीटर के साथ वापस जाना और अन्य संसाधन की तुलना में हो सके। मैं नहीं मानता कि कोई एक तरीका या कोई नियम है। आप दोनों तरीकों को लागू कर सकते हैं और कॉल करने वाले को यह तय करने की अनुमति दे सकते हैं कि सिस्टम में पहली बार प्रवेश करने के आधार पर वह अधिक उपयुक्त है।

टिप्पणियाँ

मैं दूसरों की पठनीय टिप्पणियों से असहमत हूं। इसके बावजूद कि कुछ लोग सोच सकते हैं कि REST अभी भी मानव उपभोग के लिए नहीं है। यह मशीन की खपत के लिए है। अगर मैं अपने ट्वीट्स देखना चाहता हूं तो मैं ट्विटर्स नियमित वेबसाइट का उपयोग करता हूं। मैं उनके API के साथ REST GET नहीं करता। अगर मैं अपने ट्वीट्स के साथ प्रोग्राम करना चाहता हूं तो मैं उनके REST API का उपयोग करता हूं। हां API को समझा जाना चाहिए, लेकिन आपका gteयह बुरा नहीं है, यह सिर्फ सहज नहीं है।

REST के साथ दूसरी मुख्य बात यह है कि आपको अपने एपीआई में किसी भी बिंदु पर शुरू करने में सक्षम होना चाहिए और समय से पहले अन्य संसाधनों का सटीक URL पता किए बिना अन्य सभी संबद्ध संसाधनों पर नेविगेट करना चाहिए। GETआरईएसटी में वीईआरबी के परिणामों को उन संसाधनों के पूर्ण रीस्ट URL को वापस करना चाहिए जो इसे संदर्भित करते हैं। इसलिए किसी क्वेरी के बजाय किसी Personऑब्जेक्ट की आईडी लौटाने पर , यह पूरी तरह से क्वालिफाइड URL जैसे कि लौटा देगा http://server/api/people/13। फिर आप हमेशा प्रोग्राम को परिणामी रूप से नेविगेट कर सकते हैं भले ही URL बदल गया हो।

टिप्पणी करने के लिए प्रतिक्रिया

वास्तविक दुनिया में वास्तव में ऐसी चीजें होती हैं जिन्हें बनाने की जरूरत नहीं है, पढ़ें, अपडेट करें या अपडेट करें (CRUD) एक संसाधन।

संसाधनों पर अतिरिक्त कार्रवाई की जा सकती है। विशिष्ट संबंधपरक डेटाबेस संग्रहीत प्रक्रियाओं की अवधारणा का समर्थन करते हैं। ये अतिरिक्त कमांड हैं जिन्हें डेटा के सेट पर निष्पादित किया जा सकता है। REST के पास स्वाभाविक रूप से वह अवधारणा नहीं है। और कोई कारण नहीं होना चाहिए। इस प्रकार की क्रियाएं RPC या SOAP वेब सेवाओं के लिए एकदम सही हैं।

यह सामान्य समस्या है जिसे मैं REST API के साथ देखता हूं। डेवलपर्स वैचारिक सीमाओं को पसंद नहीं करते हैं जो REST को घेरते हैं इसलिए वे इसे जो कुछ भी करना चाहते हैं उसे करने के लिए अनुकूलित करते हैं। हालांकि यह एक RESTful सेवा होने से टूटता है। अनिवार्य रूप से उन URL के GETछद्म-अनुष्ठान-जैसे सर्वलेट्स पर कॉल बन जाते हैं।

आपके पास कुछ विकल्प हैं:

• कार्य संसाधन बनाएँ
• POSTकार्रवाई करने के लिए संसाधन में अतिरिक्त डेटा का समर्थन करें ।
• SOAP वेब सेवा के माध्यम से अतिरिक्त कमांड जोड़ें।

यदि आप एक क्वेरी पैरामीटर का उपयोग करते हैं, जिसे HTTP VERB आप ईमेल को फिर से भेजने के लिए उपयोग करेंगे?

• GET- क्या यह ईमेल को फिर से भेज देता है और संसाधन का डेटा वापस कर देता है? क्या होगा यदि कोई सिस्टम उस URL को कैश करता है और उसे उस संसाधन के लिए अद्वितीय URL की तरह मानता है। हर बार जब वे यूआरएल को हिट करते हैं तो यह एक ईमेल को फिर से भेज देगा।
• POST - आपने वास्तव में संसाधन के लिए कोई नया डेटा नहीं भेजा, बस एक अतिरिक्त क्वेरी पैरामीटर।

दी गई सभी आवश्यकताओं के आधार पर, एक POST डेटा के रूप POSTमें संसाधन पर action fieldकरने से समस्या हल हो जाएगी।

Comments

जबकि HTTP के माध्यम से लागू किया गया REST आपको उन 4 क्रियाओं को देता है, मुझे यकीन नहीं है कि उन क्रियाओं का अंत होना चाहिए। वास्तविक दुनिया में वास्तव में ऐसी चीजें होती हैं जिन्हें बनाने की जरूरत नहीं है, पढ़ें, अपडेट करें या अपडेट करें (CRUD) एक संसाधन। ईमेल को फिर से भेजना उन चीजों में से एक है। मुझे डेटाबेस में कुछ भी संग्रहीत या संशोधित करने की आवश्यकता नहीं है। यह केवल एक क्रिया है जो या तो सफल होती है या विफल।

— जस्टिन वॉर्केंटिन

@JustinWarkentin मैं समझता हूं कि आपकी जरूरतें क्या हैं। लेकिन इससे REST कुछ ऐसा नहीं होता जो यह नहीं है। URL में एक नई क्रिया जोड़ना REST आर्किटेक्चर के खिलाफ है। मैं एक और विकल्प देने के लिए अपने उत्तर को अपडेट करूंगा जो कि RESTful होगा।

— एंड्रयू टी फिनेल

@JustinWarkentin ने मेरे जवाब में 'REST - POST को ट्रिगर करने की क्रियाओं' का उपयोग किया है।

— एंड्रयू टी फिनेल

Answer 3

प्रश्न 1: क्या किसी संसाधन यूआरआई [या] के साथ किसी प्रकार की एक्शन कॉल को मिलाना उचित है [] बेहतर होगा कि कार्रवाई को निर्दिष्ट करें और इसके लिए संसाधन आईडी पास करें?

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

प्रश्न 2: तुलना ऑपरेटर का उपयोग करने के बारे में ऐसा है:/collection?someField:gte=someval

जबकि यह तकनीकी रूप से ठीक है, यह शायद एक बुरा विचार है। REST के प्रमुख सिद्धांतों में से एक पठनीयता है। मेरा सुझाव है कि आप तुलना ऑपरेटर को एक अन्य पैरामीटर के रूप में पास करें, उदाहरण के लिए: /collection?someField=someval&operator=gteऔर निश्चित रूप से अपने एपीआई को डिज़ाइन करें ताकि यह डिफ़ॉल्ट मामले के लिए पूरा हो जाए (इस घटना में कि operatorपैरामीटर यूआरआई से बचा हुआ है)।

प्रश्न 3: क्या वास्तव में एक REST URI के दो स्तरों से अधिक गहरे होने का एक अच्छा कारण है?

हाँ; अमूर्तता के लिए। मैंने कुछ UEST API देखे हैं, जो कई URI स्तरों के माध्यम से अमूर्तता की परतों का उपयोग करते हैं, उदाहरण के लिए: /vehicles/cars/123या /vehicles/bikes/123जो बदले में आपको दोनों /vehiclesऔर /vehicles/bikesसंग्रह से संबंधित उपयोगी जानकारी के साथ काम करने की अनुमति देता है । ऐसा कहने के बाद, मैं इस दृष्टिकोण का बहुत बड़ा प्रशंसक नहीं हूं; आपको शायद ही कभी ऐसा करने की आवश्यकता होगी, और संभावना है कि आप एपीआई को केवल 2 स्तरों का उपयोग करने के लिए पुनः डिज़ाइन कर सकते हैं।

और हाँ, जैसा कि ऊपर दिए गए सुझाव हैं, भविष्य में आपके प्रश्नों को अलग-अलग पोस्ट में विभाजित करना सबसे अच्छा होगा;)

Comments

मुझे लगता है कि प्रश्न # 2 के लिए मेरा उदाहरण सरल था। मुझे संग्रह को फ़िल्टर करने के लिए उपयोग किए जाने वाले प्रत्येक क्षेत्र के लिए एक तुलना ऑपरेटर निर्दिष्ट करने की आवश्यकता है, न कि केवल एक, इसलिए आपके उदाहरण में इसे कुछ पसंद करना होगा /collection?field1=someval&field1Operator=gte&field2=someval&field2Operator=eq।

— जस्टिन वारकेंटिन

Answer 4

प्रश्न 2 के लिए, एक अलग विकल्प अधिक लचीला हो सकता है: प्रत्येक खोज को एक संसाधन पर विचार करें जो उपयोगकर्ता उपयोग करने से पहले बनाता है।

मान लें कि आपके पास "खोज" कंटेनर है, वहां आप POST /api/searches/सामग्री पर क्वेरी विनिर्देश के साथ करते हैं। यह एक JSON, XML या यहां तक ​​कि SQL दस्तावेज़ भी हो सकता है, जो भी आपके लिए आसान है। यदि क्वेरी सही ढंग से पार्स करती है, तो एक नया खोज अपने स्वयं के URI के साथ एक नए संसाधन के रूप में बनाया जाता है, आइए बताते हैं/api/searches/q123/

फिर, क्लाइंट केवल GET /api/searches/q123/क्वेरी परिणामों को पुनः प्राप्त कर सकता है ।

अंत में, आप ग्राहक से क्वेरी को हटाने के लिए कह सकते हैं, या सत्र बंद करने के बाद उसे शुद्ध कर सकते हैं।

Answer 5

क्या किसी संसाधन URI (जैसे / संग्रह / 123? क्रिया = resendEmail) के साथ किसी प्रकार की कार्रवाई कॉल को मिलाना उचित है? क्या कार्रवाई को निर्दिष्ट करना और इसके लिए संसाधन आईडी पास करना बेहतर होगा (जैसे / संग्रह / पुनः भेजें? Id = 123)? क्या यह इसके बारे में गलत तरीका है? परंपरागत रूप से (कम से कम HTTP के साथ) किया जा रहा कार्य अनुरोध विधि (GET, POST, PUT, DELETE) है, लेकिन वे वास्तव में किसी संसाधन के साथ कस्टम क्रियाओं की अनुमति नहीं देते हैं।

नहीं, यह उचित नहीं है, क्योंकि IRI संसाधनों की पहचान करने के लिए हैं न कि संचालन के लिए (हालाँकि ppl इस विधि का उपयोग ओवरराइड दृष्टिकोण को कुछ समय के लिए करते हैं, ऐसे मामलों में जब गैर POST और GET विधियों का उपयोग नहीं किया जाता है)। आप जो कर सकते हैं वह उचित HTTP विधि की तलाश में है, या एक नया बनाएं। इन मामलों में POST आपका मित्र हो सकता है (यदि उन्हें उपयुक्त विधि नहीं मिल सकती है और अनुरोध पुनर्प्राप्ति नहीं है तो कृपया इसका उपयोग करें) ईमेल भेजने से संसाधन बनाने के लिए एक और तरीका और POST /emailsएक वास्तविक संसाधन बनाए बिना मेल भेज सकता है। Btw। URI संरचना शब्दार्थ को नहीं ढोती है, इसलिए REST के दृष्टिकोण से यह वास्तव में मायने नहीं रखता कि आप किस तरह के URI का उपयोग करते हैं। क्या मायने रखता है मेटा-डेटा (जैसे लिंक संबंध ) जो आपको ग्राहकों को भेजे गए लिंक को सौंपा गया है।

अब तक जो सबसे अच्छा विचार आया है, वह यह है कि एपीआई उपयोगकर्ता को इसे क्षेत्र के नाम के लिए एक उपांग के रूप में निर्दिष्ट करने की अनुमति है (जैसे / संग्रह; someField: gte = someval - यह इंगित करने के लिए कि इसे संसाधनों को वापस करना चाहिए जहां someField से अधिक है या इसके (> =) के बराबर जो कुछ भी है। क्या यह एक अच्छा विचार है? एक बुरा विचार? यदि हां, तो क्यों? उपयोगकर्ता को दिए गए क्षेत्र और मूल्य के साथ प्रदर्शन करने के लिए तुलना के प्रकार को निर्दिष्ट करने की अनुमति देने का एक बेहतर तरीका है?

आपको अपनी क्वेरी भाषा बनाने की आवश्यकता नहीं है। मैं पहले से मौजूद एक का उपयोग करूंगा और लिंक मेटा-डेटा में कुछ क्वेरी विवरण जोड़ूंगा। आपको शायद ऐसा करने के लिए RDF मीडिया प्रकार (जैसे JSON-LD) का उपयोग करना चाहिए या कस्टम MIME प्रकार का उपयोग करना चाहिए (afaik इसमें कोई गैर-RDF प्रारूप नहीं है जो इसका समर्थन करता है)। मौजूदा मानकों का उपयोग करते हुए अपने क्लाइंट को सर्वर से अलग करें, यही एक समान इंटरफ़ेस बाधा है।

यह / कुत्तों के बराबर होगा? व्यक्ति = 123। क्या वास्तव में एक REST URI के दो स्तरों से अधिक गहरे (/ संग्रह / संसाधन_id) होने का एक अच्छा कारण है?

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

मैंने कई घंटों तक अथक खोज की है, लेकिन मुझे कहीं भी अपने सवालों के जवाब नहीं मिले हैं (हो सकता है कि मुझे अभी पता नहीं है कि क्या खोजा जाए?)।

आपको कम से कम REST बाधाओं को फ़ील्डिंग शोध प्रबंध , HTTP मानक और शायद 3rd जनरेशन वेब APIs Markus से पढ़ना चाहिए ।