तो मैं अपने मौसम पूर्वानुमान डेटा (10000 स्थानों, 40 पैरामीटर प्रत्येक, अगले 14 दिनों के लिए प्रति घंटा मूल्य = लगभग 130 मिलियन मूल्यों) तक पहुंचने के लिए एक webservice पर काम कर रहा हूं।बड़े डेटा सेट के संदर्भ में एक विश्वसनीय संसाधन क्या है, i.E. मौसम डेटा?
तो मैंने रीस्टफुल सेवाओं और इसकी विचारधारा के बारे में सब कुछ पढ़ा।
तो मैं समझता हूं कि एक यूआरएल एक रिसोर्स को संबोधित कर रहा है।
लेकिन मेरे मामले में एक रिसोर्स है?
सामान्य उपयोग केस यह है कि आप एक या अधिक स्थान पर एक समय पर दो पैरामीटर के लिए डेटा प्राप्त करना चाहते हैं। तो स्पष्ट रूप से प्रत्येक मूल्य को अपना यूआरएल देना प्रैक्टिकल नहीं है और इसके परिणामस्वरूप सैकड़ों अनुरोध होंगे। मुझे यह महसूस हो रहा है कि मेरी विशिष्ट समस्या अस्थिर रूप से रीस्टफुल पैटर्न में फिट नहीं होती है।
अद्यतन: स्पष्ट करने के लिए: सेवा के दो उपयोग पैटर्न हैं। 1. कच्चा डेटा; कई स्थानों और मानकों के लिए डेटा की पंक्तियां और पंक्तियां।
- व्याख्या डेटा; कच्चे डेटा प्रतीकों में गणना की जाती है (उदाहरण के लिए सन & बादल) और अन्य पैरामीटर।
वहाँ एक 'पूर्वानुमान' नहीं है। विभिन्न ग्राहकों के डेटा के लिए अलग-अलग ज़रूरतें हैं।
कारण मुझे लगता है कि यह बाकी पैटर्न में फ़िट नहीं होता है, कि मैं वास्तव में एक 'पूर्वानुमान' ressource हो सकता है, जबकि, मैं अभी भी अनुरोध पैरामीटर का एक बहुत प्रस्तुत करने के लिए किया है। इसलिए एक रिसोर्स पर एक सरल जीईटी अनुरोध काम नहीं करता है, मैं जगह पर पोस्टिंग डेटा समाप्त करता हूं।
आपके इनपुट के लिए धन्यवाद, मैंने अपनी पोस्ट में थोड़ा सा स्पष्टीकरण देने की कोशिश की। –
@ क्रिस्टियन, आपका संपादन इंगित करता है कि कोई भी "पूर्वानुमान" नहीं है - कोई समस्या नहीं है। लेकिन असली सवाल यह है कि: डोमेन अवधारणा के रूप में "पूर्वानुमान" कितना महत्वपूर्ण है? क्लाइंट की ज़रूरतों के आधार पर एक ही संसाधन में कई प्रतिनिधित्व हो सकते हैं, लेकिन संसाधन एक आम तौर पर लागू डोमेन अवधारणा है जिसे इसे अपने प्रतिनिधित्व के स्वतंत्र रूप से मॉडलिंग किया जा सकता है। इसे रखने का एक और तरीका: अपनी सेवा का उपयोग कर ग्राहक की कल्पना करें। यह क्या है कि वे बनाने की कोशिश कर रहे हैं या वे क्या करने की कोशिश कर रहे हैं? –
हम्म, इसके लिए धन्यवाद, मैं अब थोड़ा और स्पष्ट रूप से देख सकता हूं ... –