रीस्टफुल सेवा आर्किटेक्चर प्रश्न

Question

यह सेवा वास्तुकला रणनीति के बारे में अधिक प्रश्न है, हम बैक एंड पर बाकी सेवाओं के आधार पर बड़ी वेब प्रणाली का निर्माण कर रहे हैं। और हम वर्तमान में बाकी सेवाओं को विकसित करते समय पालन करने के लिए कुछ आंतरिक मानकों का निर्माण करने की कोशिश कर रहे हैं।

कुछ प्रश्नों संस्थाओं की सूची देता है, उदाहरण के लिए विचार करना हम सेवा को पुन: प्राप्त छवि गैलरी देता है:/gell_all_galeries, अगले प्रतिक्रिया लौटाएँ:

<galleries> 
    <gallery> 
     <id>some_gallery_id</id> 
     <name>my photos</name> 
     <photos> 
      <photo> 
       <id>123</id> 
       <name>my photo</name> 
       <location>http://mysite/photo/show/123</location> 
       ...... 
       <author> 
        <id>some_id</id> 
        <name>some name</name> 
        ....... 
       <author> 
      </photo> 
      <photo> ..... </photo> 
      <photo> ..... </photo> 
      <photo> ..... </photo> 
      <photo> ..... </photo> 
    </photos> 
    </gallery> 
    <gallery> .... </gallery> 
    <gallery> .... </gallery> 
    <gallery> .... </gallery> 
    <gallery> .... </gallery> 
</galleries> 

आप यहाँ देख के रूप में, प्रतिक्रिया काफी बड़े और भारी, और हमेशा नहीं हमें ऐसी गहरी जानकारी स्तर की आवश्यकता है। हमेशा की तरह समाधान का उपयोग करें या बजाय प्रत्येक गैलरी के लिए http://ru.wikipedia.org/wiki/Atom तत्वों पूर्ण गैलरी डेटा के लिए है:

<galleries> 
    <gallery> 
     <id>some_gallery_id</id> 
     <link href="http://mysite/gallery/some_gallery_id"/> 
    </gallery> 
    <gallery> 
     <id>second_gallery_id</id> 
     <link href="http://mysite/gallery/second_gallery_id"/> 
    </gallery> 
    <gallery> .... </gallery> 
    <gallery> .... </gallery> 
    <gallery> .... </gallery> 
    <gallery> .... </gallery> 
</galleries> 

पहला सवाल, बगल में है: शायद बजाय हम भी इस्तेमाल करना चाहिए नहीं और प्रकार, और सिर्फ सामान्य उपयोग करें और सभी संसाधनों के लिए कि वापसी सूची वस्तुओं:

<list> 
    <item><link href="http://mysite/gallery/some_gallery_id"/></item> 
    <item><link href="http://mysite/gallery/other_gallery_id"/></item> 
    <item>....</item> 
</list> 

और दूसरा सवाल है, उपयोगकर्ता के बाद कुछ ठोस गैलरी के बारे में जानकारी प्राप्त करने का प्रयास है, वह उदाहरण http://mysite/gallery/some_gallery_id लिंक के लिए इस्तेमाल करेंगे, वह परिणाम के रूप में क्या देखना चाहिए?

यह होना चाहिए:

<gallery> 
     <id>some_gallery_id</id> 
     <name>my photos</name> 
     <photos> 
      <photo> 
       <id>123</id> 
       <name>my photo</name> 
       <location>http://mysite/photo/show/123</location> 
       ...... 
       <author> 
        <id>some_id</id> 
        <name>some name</name> 
        ....... 
       <author> 
      </photo> 
      <photo> ..... </photo> 
      <photo> ..... </photo> 
      <photo> ..... </photo> 
      <photo> ..... </photo> 
    </photos> 
    </gallery> 

या:

<gallery> 
     <id>some_gallery_id</id> 
     <name>my photos</name> 
     <photos> 
      <photo><link href="http://mysite/photo/11111"/></photo> 
      <photo><link href="http://mysite/photo/22222"/></photo> 
      <photo><link href="http://mysite/photo/33333"/> </photo> 
      <photo> ..... </photo> 
    </photos> 
    </gallery> 

या

<gallery> 
     <id>some_gallery_id</id> 
     <name>my photos</name> 
     <photos> 
      <photo> 
       <link href="http://mysite/photo/11111"/> 
       <author> 
        <link href="http://mysite/author/11111"/> 
       </author> 
      </photo> 
      <photo> 
       <link href="http://mysite/photo/22222"/> 
       <author> 
        <link href="http://mysite/author/11111"/> 
       </author> 
      </photo> 
      <photo> 
       <link href="http://mysite/photo/33333"/> 
       <author> 
        <link href="http://mysite/author/11111"/> 
       </author> 
      </photo> 
      <photo> ..... </photo> 
    </photos> 
    </gallery> 

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

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

Answer 1

आप हमेशा विशेषताओं का उपयोग कर सकते हैं।

<gallery id = "1" name = "Gallery 1"> 
     <photos> 
      <photo id="1" link="http://mysite/photo/11111" /> 
      <photo id="2" link="http://mysite/photo/22222" /> 
      <photo id="3" link="http://mysite/photo/33333" /> 
     </photos> 
    </gallery> 

या आप जेएसओएन का उपयोग कर सकते हैं मैं इसे एक्सएमएल की तुलना में आसान और हल्का से पसंद करता हूं।

{ 
    "gallery": { 
     "id": "1", 
     "name": "Gallery 1", 
     "photos": [ 
      { 
       "id": "1", 
       "link": "http://mysite/photo/11111" 
      }, 
      { 
       "photo": "2", 
       "link": "http://mysite/photo/22222" 
      }, 
      { 
       "photo": "3", 
       "link": "http://mysite/photo/33333" 
      } 
     ] 
    } 

Answer 2

विचार करने के लिए एक अच्छी बात यह है कि आप ग्राहकों को डेटा पुनर्प्राप्त करने का इरादा रखते हैं। यदि आप किसी ग्राहक के लिए कई फ़ोटो के बारे में जानकारी का पूरा समूह पकड़ने का इरादा रखते हैं, तो केवल <photo href="..."/> की एक सूची इष्टतम नहीं हो सकती है, क्योंकि क्लाइंट को प्रत्येक फोटो संसाधन के लिए एक जीईटी अनुरोध करने के लिए मजबूर होना होगा, जिसके बारे में उन्हें जानकारी चाहिए ।

मैं अपने सिर के ऊपर से इस बारे में कुछ दिलचस्प तरीकों के बारे में सोच सकता हूं।

आप क्लाइंट को उन फ़ील्ड को निर्दिष्ट करने की अनुमति दे सकते हैं जिन्हें वे क्वेरी पूछताछ करते समय क्वेरी पैरामीटर के रूप में पुनर्प्राप्त करना चाहते हैं, उदा।:

GET http://www.example.com/photos?_fields=author,fileSize 

यह तो की तरह कुछ लौट सकता है:

<photos href="/photos?_fields=author,fileSize"> 
    <photo href="/photos/15"> 
     <author href="/authors/2245"/> 
     <fileSize>32MB</fileSize> 
    </photo> 
    ... 
</photos> 

वैकल्पिक रूप से, अधिक से अधिक "गहराई" संपत्ति के कुछ प्रकार निर्दिष्ट करने के लिए ग्राहक की अनुमति देकर आप इसे सरल बनाने सकता है, यह थोड़ा और कच्चा है, लेकिन प्रभावी ढंग से इस्तेमाल किया जा सकता है। उदाहरण के लिए, यदि क्लाइंट ने 2 की गहराई निर्दिष्ट की है, तो आप <gallery> के साथ-साथ प्रत्येक <photo> के सभी बाल तत्वों के तहत सबकुछ वापस कर देंगे।

GET /galleries?depth=2 

की तरह कुछ वापस कर सकती है:

<galleries> 
    <id>22</id> 
    <name>My Gallery</name> 
    <!-- full gallery data --> 
    <photos href="/photos?gallery=/galleries/22"> 
    <photo href="/photos/99"> 
     <id>99</id> 
     <author href="/authors/4381"/><!-- href instead of including nested author data --> 
     <fileSize>24MB</fileSize> 
     <!-- full photo data --> 
    </photo> 
    ... 
    </photos> 
</galleries> 

इस के साथ-साथ, अगर आप ग्राहक एक बार में कई, कई रिकॉर्ड की क्वेरी को लेकर चिंतित हैं (उदाहरण के लिए अगर वहाँ फोटो या दीर्घाओं के हजारों रहे हैं), आप अपनी सूचियों के लिए कुछ प्रकार की पेजिंग पर विचार करना चाहेंगे।

GET /photos?gallery=/galleries/59 

लौट सकता है:: यह अपने कोड में परिणाम के लिए एक कठिन अधिकतम स्थापित करने और अगले/पिछले पृष्ठों के लिंक के साथ ग्राहक प्रदान शामिल हो सकता है

<photos href="/photos?gallery=/galleries/59&_max=100&_first=100" next="/photos?gallery=/galleries/59&_max=100&_first=200" prev="/photos?gallery=/galleries/59&_max=100&_first=0" count="100" total="3528"> 
    .... 
</photos> 

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

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

Answer 3

"मेरे मीडिया प्रकारों को कैसे डिजाइन करना चाहिए" के लिए वास्तव में कोई सही या गलत जवाब नहीं है। हालांकि, नए मीडिया प्रकारों को मौजूदा और डिज़ाइन करते समय कुछ बहुत ही महत्वपूर्ण दिशानिर्देश दिए गए हैं।

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

प्रतिक्रियाओं के आकार को अनुकूलित करना प्रदर्शन के लिए महत्वपूर्ण हो सकता है, लेकिन कैशिंग अधिक महत्वपूर्ण है। तार में 0 बाइट भेजना हमेशा अधिक कुशल होता है।

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

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

बनाने के साथ गलत कुछ भी नहीं है:

/gallery/foo/quickview 
/gallery/foo/detailedview 
/gallery/foo/justlinks 

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

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

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

Answer 4

यह वास्तव में आपके परिदृश्य पर निर्भर करता है। आपको यह जानने की जरूरत है कि क्लाइंट इसका उपयोग कैसे कर रहा है यह जानने के लिए कि आपके Resource Proxies को कैसे डिज़ाइन किया जाए।

मेरा सुझाव है कि आप "पसंद चौराहे" में खो जाएंगे। क्लाइंट उपयोग के बारे में आप जो भी मानते हैं उसके आधार पर बस एक कार्यान्वयन के साथ जाएं। देखें कि पूरी चीज का उपयोग कैसे किया जाता है और व्यवहार करता है, यदि आवश्यक हो तो बाद में ठीक ट्यून करें। धोना और सुखाना। दोहराएँ। यह स्थायी बीटा तरीका करें :)