उपयोगकर्ता देखने के विशेषाधिकारों के आधार पर विभिन्न आरईएसटी संसाधन सामग्री

Question

मैं एक्सेस अधिकारों के आधार पर विभिन्न उपयोगकर्ताओं के लिए एक ही प्रश्न के अलग-अलग उत्तर प्रदान करना चाहता हूं। मैं इस सवाल पढ़ें:

Excluding private data in RESTful response

लेकिन मैं स्वीकार किए जाते हैं जवाब है, जिसमें कहा गया है कि आप, दोनों /people.xml और /unauthenticated/people.xml प्रदान करना चाहिए के बाद से बाकी की मेरी समझ है कि एक विशेष संसाधन एक में रहते हैं चाहिए से सहमत नहीं हूं विशेष स्थान, इस पर निर्भर करता है कि आपकी कितनी जानकारी में रुचि है।

मैं जिस सिस्टम को डिजाइन कर रहा हूं वह उससे भी जटिल है। मान लीजिए कि एक उपयोगकर्ता ने दोस्तों की कई मंडलियां बनाई हैं, और उन्हें विभिन्न पहुंच अधिकार सौंपे हैं। उदाहरण के लिए, मेरे "परिचितों" सर्कल के पास मेरे जन्मदिन तक पहुंच हो सकती है, और मेरे "पेशेवर" सर्कल के पास मेरे रोजगार इतिहास तक पहुंच हो सकती है, लेकिन दूसरी तरफ नहीं। मेरे द्वारा उल्लिखित प्रश्न से उत्तर लागू करने के लिए, मुझे सभी उपयोगकर्ता की मंडलियों (जो मैं सुरक्षा कारणों से गुप्त रखना चाहता हूं) प्राप्त करने का एक तरीका प्राप्त करने की आवश्यकता है, और फिर /circles/a/users/42, /circles/b/users/42, /circles/c/users/42 और इसी तरह से आगे बढ़ने की आवश्यकता है , और उसके बाद उपलब्ध अधिकतम मात्रा में जानकारी प्रदर्शित करने के लिए परिणामों को मर्ज करें। स्पष्ट रूप से एक भी सर्कल नहीं है जो सभी जानकारी प्राप्त करता है कि किसी भी अन्य मंडल में मिलता है। मेरा मानना ​​है कि यह काफी मुश्किल है (ध्यान दें कि मुझे शायद इसे कई प्रकार की वस्तुओं के साथ करने की आवश्यकता है और भविष्य के संस्करणों को एक अलग प्रक्रिया की आवश्यकता हो सकती है), लेकिन अगर मैं किसी विशेष उपयोगकर्ता पर सुरक्षा प्रतिबंध लगा देना चाहता हूं तो तथ्य कि वह मेरी कुछ मंडलियों में भी है? क्या उस समस्या को भी हल किया जा सकता है? यहां तक ​​कि यदि मैं उपरोक्त उल्लिखित प्रश्नों में से किसी एक का जवाब देने से इनकार करता हूं और एक नया व्यक्ति हूं जो मुझे जवाब दे सकता है, तो यह अभी भी इस तथ्य को प्रकट करेगा कि व्यक्तिगत पहुंच प्रतिबंधों के कारण इस विशिष्ट उपयोगकर्ता का अलग-अलग व्यवहार किया जाता है।

मुझे यहां क्या याद आ रही है? क्या मेरे लिए एक शानदार वेब सेवा विकसित करना भी संभव है?

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

Answer 1

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

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

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

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

Answer 2

फील्डिंग के शोध प्रबंध के अनुसार (यह वास्तव में एक महान लेखन है):

एक संसाधन संस्थाओं का एक सेट करने के लिए एक वैचारिक मानचित्रण है, नहीं इकाई है कि समय में किसी खास बिंदु पर मानचित्रण से मेल खाती है।

दूसरे शब्दों में, यदि आप एक संसाधन है कि /projects की एक यूआरआई द्वारा पहुँचा जा सकता तत्संबंधी के रूप में "का अनुरोध उपयोगकर्ता की सौंपा परियोजनाओं" और अभ्यावेदन परिभाषित किया गया है है, तो आप बाकी में से किसी की कमी परियोजनाओं में से एक सूची वापस लौट कर का उल्लंघन नहीं करते (यानी, प्रतिनिधित्व) उपयोगकर्ता बी के लिए उपयोगकर्ता ए और अन्य (प्रतिनिधित्व) के लिए जब वे उसी यूआरआई प्राप्त करते हैं। इस तरह, इंटरफ़ेस वर्दी/संगत है।

इस के अलावा, बाकी केवल प्रावधान है कि एक स्पष्ट कैशिंग अनुदेश, प्रतिक्रिया के साथ शामिल किया जाना है कि क्या है कि 'यह लंबे समय के लिए कैश' है या 'सब पर कैश नहीं है':

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

आप इसे प्रबंधित करने के लिए कैसे चुनते हैं आप पर निर्भर है।

कि ध्यान में रखते हुए,

आप एक संसाधन उपयोगकर्ता पर निर्भर करता है कि एक विशेष संसाधन का प्रतिनिधित्व प्राप्त करने के लिये एक प्रतिनिधित्व लौटने सहज महसूस करना चाहिए, जब तक कि आप बाध्यताओं का उल्लंघन नहीं कर रहे हैं के रूप में एक समान इंटरफ़ेस का - विभिन्न संसाधनों के प्रतिनिधित्व को वापस करने के लिए एकल संसाधन पहचानकर्ता का उपयोग न करें।

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