मैं एक विश्वसनीय कैलक्यूलेटर कैसे बना सकता हूं?

Question

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

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

Answer 1

एक कैलकुलेटर सेवा एक यथार्थ तरीके से मॉडल के लिए आसान होगी। "सीआरयूडी" में "आर" का अर्थ "पढ़ना" है, और इसका कोई कारण नहीं है कि "पढ़ना" का अर्थ "गणना" भी नहीं हो सकता है। तो एक सरल Reverse Polish कैलकुलेटर सेवा प्राप्त द्वारा ही पहुंचा जा सकता है:

3 
4 
+ (URL-encoded as %2B) 

एक idempotent, सुरक्षित और संचित करने योग्य अनुरोध है कि:

GET https://calc.com/rpnCalc?3&4&%2B 
7 

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

आपको जिस तरह की गणना करने की आवश्यकता है, उसके आधार पर, आप कैलक्यूलेटर संसाधन (अनुरोध निकाय के रूप में क्वेरी में गुजरने) के लिए एक बहुत ही जटिल क्वेरी पोस्ट कर सकते हैं और सर्वर यूआरआई को "परिणाम" संसाधन में वापस कर सकता है , जिसे आप परिणाम पुनर्प्राप्त करने के लिए प्राप्त कर सकते हैं, और यहां तक ​​कि उनके माध्यम से भी अंकन कर सकते हैं।

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

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

अरे, अगर एसओएपी आपकी आवश्यकताओं के अनुरूप है, तो इसमें है। आरईएसटी का उपयोग करने के कई फायदे हैं लेकिन वे आपकी स्थिति के लिए उपयुक्त नहीं हो सकते हैं। कम से कम, आरईएसटी आपको एक सभ्य पुस्तक like this one के साथ क्या दे सकता है और फिर पूर्ण कहानी प्राप्त करने के बाद अपना मन बनाओ।

Answer 2

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

Answer 3

एक HTTP पोस्ट को एक सतत संसाधन बनाने की आवश्यकता नहीं है। RFC 2616, section 9.5 में हम पाते हैं:

POST विधि द्वारा किया जाता कार्रवाई एक संसाधन कि एक URI के आधार पर पहचाना जा सकता है में परिणाम नहीं हो सकता है। इस मामले में, पर निर्भर करता है या नहीं, प्रतिक्रिया में एक इकाई शामिल है जो परिणाम का वर्णन करती है या नहीं, इस मामले में, 200 (ठीक) या 204 (कोई सामग्री नहीं) उचित प्रतिक्रिया स्थिति है।

इसका मतलब है कि हम उस गणना के परिणाम को अपने स्वयं के यूआरएल पर जारी रखने के बिना "गणना बनाना" के बारे में सोच सकते हैं। आपका एपीआई ऐसा दिखाई दे सकता:

Request: 
POST /calculations 
Content-Type: text/plain 

3 + 3/12^(3 * PI) 

Response: 
200 OK 
Content-Type: text/plain 

3.005454 

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

Answer 4

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

लेकिन एक साधारण कैलकुलेटर के लिए, मुझे लगता है कि नीचे जेएक्सआरएस कार्यान्वयन एक स्वच्छ एपीआई प्रदान करता है।

/** 
* This class defines a CalculatorResource. 
*/ 

@Path("v{version}/calculators/{id}") 
@Named 
public class CalculatorResource { 

    private final Long value; 

    public CalculatorResource() { 
     value = 0L; 
    } 

    public CalculatorResource(Long initialValue) { 
     this.value = initialValue; 
    } 

    @GET 
    public Long getValue() { 
     return value; 
    } 

    @Path("+{value}") 
    public CalculatorResource add(@PathParam("value") Long value) { 
     return new CalculatorResource(this.value + value); 
    } 

    @Path("-{value}") 
    public CalculatorResource subtract(@PathParam("value") Long value) { 
     return new CalculatorResource(this.value - value); 
    } 

    @Path("*{value}") 
    public CalculatorResource multiply(@PathParam("value") Long value) { 
     return new CalculatorResource(this.value * value); 
    } 

} 

---

इस तरह के एक अंतर्गत प्रयोग के साथ

, यूआरआई एक आसान सूत्र पढ़ने के लिए हो सकता है।

ईजी।/एपीआई/वी 1/कैलकुलेटर/mycalc/+ 9/-4/* 3/+ 10 25.