जंग में सामान्यीकृत प्रोग्रामिंग तकनीक: हमने एक्सोनम का लोहा से एक्टिक्स-वेब में अनुवाद कैसे किया

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

एक्टिक्स-वेब को आयरन के प्रतिस्थापन के रूप में चुना गया था। आगे मैं बताऊंगा कि कैसे हमने सामान्यीकृत प्रोग्रामिंग तकनीकों का उपयोग करके मौजूदा कोड को एक नए समाधान में पोर्ट किया।


अल्लेओ पीडी की छवि

हमने आयरन का उपयोग कैसे किया

एक्सोनम में, लोहे के ढांचे का उपयोग बिना किसी सार के किया गया था। हमने कुछ संसाधनों पर हैंडलर स्थापित किए, सहायक विधियों का उपयोग करके URL को पार्स करके क्वेरी पैरामीटर प्राप्त किए, और परिणाम को केवल एक स्ट्रिंग के रूप में वापस किया।

यह सब कुछ इस तरह दिखता था:

fn set_blocks_response(self, router: &mut Router) { let blocks = move |req: &mut Request| -> IronResult<Response> { let count: usize = self.required_param(req, "count")?; let latest: Option<u64> = self.optional_param(req, "latest")?; let skip_empty_blocks: bool = self.optional_param(req, "skip_empty_blocks")? .unwrap_or(false); let info = self.blocks(count, latest.map(Height), skip_empty_blocks)?; self.ok_response(&::serde_json::to_value(info).unwrap()) }; router.get("/v1/blocks", blocks, "blocks"); } 

इसके अलावा, कॉर्स हेडर के रूप में कुछ मिडलवेयर ऐड-ऑन का उपयोग किया गया था। सभी हैंडलर को एक ही एपीआई में संयोजित करने के लिए, हमने माउंट का उपयोग किया।

आपको उसे क्यों छोड़ना पड़ा

बहुत सारे परिवर्धन के साथ लोहा एक अच्छा काम था। हालांकि, यह उन दूर के समय में लिखा गया था, जब वायदा और तोकी जैसी परियोजनाएं मौजूद नहीं थीं।

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

हमने एक्टिक्स-वेब पर स्विच क्यों किया

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

बेशक, एक्टिक्स-वेब में खामियां थीं, उदाहरण के लिए, इसमें बड़ी मात्रा में असुरक्षित कोड था। लेकिन बाद में इसे सुरक्षित जंग में फिर से लिखा गया, जिसने इस समस्या को हल कर दिया।

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

हम वेब फ्रेमवर्क से क्या चाहते हैं

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

यह देखने के लिए कि यह दृश्य कैसे दिखता है, आइए परिभाषित करें कि कोई HTTP API क्या है:

• अनुरोध ग्राहकों द्वारा विशेष रूप से किए जाते हैं, और सर्वर केवल उनका उत्तर देता है (यह सर्जक के रूप में कार्य नहीं करता है)।
• अनुरोधों को पढ़ा और संशोधित किया जाता है।
• क्वेरी के परिणामस्वरूप, सर्वर एक प्रतिक्रिया देता है जिसमें, यदि सफल, वांछित डेटा समाहित है, और एक त्रुटि के मामले में, इसके बारे में जानकारी।

यदि हम अमूर्तता की सभी परतों का विश्लेषण करते हैं, तो यह पता चलता है कि कोई HTTP अनुरोध केवल एक फ़ंक्शन कॉल है:

 fn request(context: &ServiceContext, query: Query) -> Result<Response, ServiceError> 

बाकी सब कुछ इस मूल इकाई का विस्तार माना जा सकता है। इस प्रकार, वेब फ्रेमवर्क के विशिष्ट कार्यान्वयन को अनदेखा करने के लिए, हमें ऊपर उदाहरण के समान शैली में हैंडलर लिखने की आवश्यकता है।

सामान्यीकृत HTTP अनुरोध प्रसंस्करण के लिए समापन बिंदु विशेषता

आप सबसे सरल और सबसे सरल तरीके से जा सकते हैं और एक समापन बिंदु विशेषता की घोषणा कर सकते हैं,
विशिष्ट प्रश्नों के कार्यान्वयन का वर्णन:

 // ,   GET .      //    ,      . //         . trait Endpoint: Sync + Send + 'static { type Request: DeserializeOwned + 'static; type Response: Serialize + 'static; fn handle(&self, context: &Context, request: Self::Request) -> Result<Self::Response, io::Error>; } 

उसके बाद, आपको इस हैंडलर को एक विशिष्ट ढांचे में लागू करना होगा। एक्टिक्स-वेब के लिए मान लें कि यह कुछ इस तरह है:

 //    actix-web.  ,   , //  `Endpoint`   . type FutureResponse = actix_web::FutureResponse<HttpResponse, actix_web::Error>; // «»    actix-web.      //   .     , //     . type RawHandler = dyn Fn(HttpRequest<Context>) -> FutureResponse + 'static + Send + Sync; //   ,     ,     . #[derive(Clone)] struct RequestHandler { ///  . pub name: String, /// HTTP . pub method: actix_web::http::Method, ///  .  ,       . pub inner: Arc<RawHandler>, } 

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

 #[derive(Deserialize)] struct SimpleQuery { a: i32, b: String, } 

यह समापन बिंदु विशेषता से संबद्ध अनुरोध प्रकार के अनुरूप है।

अब एक एडेप्टर लिखते हैं जो एक्टिक्स-वेब के लिए रिक्वेस्टहैंडलर में एक विशिष्ट एंडपॉइंट कार्यान्वयन को लपेटता है। कृपया ध्यान दें कि अनुरोध और प्रतिक्रिया प्रकारों के बारे में जानकारी प्रक्रिया में खो गई है। इस तकनीक को टाइप इरेज़र कहा जाता है। इसका कार्य स्थैतिक समय-निर्धारण को गतिशील में बदलना है।

 impl RequestHandler { fn from_endpoint<E: Endpoint>(name: &str, endpoint: E) -> RequestHandler { let index = move |request: HttpRequest<Context>| -> FutureResponse { let context = request.state(); let future = Query::from_request(&request, &()) .map(|query: Query<E::Request>| query.into_inner()) .and_then(|query| endpoint.handle(context, query).map_err(From::from)) .and_then(|value| Ok(HttpResponse::Ok().json(value))) .into_future(); Box::new(future) }; Self { name: name.to_owned(), method: actix_web::http::Method::GET, inner: Arc::from(index) as Arc<RawHandler>, } } } 

इस स्तर पर, आप POST अनुरोधों के लिए हैंडलर जोड़ सकते हैं और रोक सकते हैं, क्योंकि हमने एक विशेषता बनाई है जो कार्यान्वयन विवरण से सारगर्भित है। हालाँकि, यह अभी भी बहुत अधिक एर्गोनोमिक नहीं है।

समस्याएं टाइप करें

हैंडलर लिखते समय, बहुत सारे सहायक कोड उत्पन्न होते हैं:

 //    . struct ElementCountEndpoint { elements: Rc<RefCell<Vec<Something>>>, } //   Endpoint. impl Endpoint for ElementCountEndpoint { type Request = (); type Result = usize; fn handle(&self, context: &Context, _request: ()) -> Result<usize, io::Error> { Ok(self.elements.borrow().len()) } } //    . let endpoint = ElementCountEndpoint::new(elements.clone()); let handler = RequestHandler::from_endpoint("/v1/element_count", endpoint); actix_backend.endpoint(handler); 

आदर्श रूप से, मैं एक हैंडलर के रूप में एक सामान्य बंद को पारित करने में सक्षम होना चाहूंगा, परिमाण के एक क्रम से वाक्यविन्यास के शोर को कम करना:

 let elements = elements.clone(); actix_backend.endpoint("/v1/elements_count", move || {   Ok(elements.borrow().len()) }); 

मैं बाद में यह करने के बारे में बात करूँगा।

सामान्य प्रोग्रामिंग में आसान विसर्जन

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

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

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

Fn प्रकार से प्रकार निकालना

जंग में, प्रत्येक बंद का अपना अलग प्रकार होता है, जिसे कार्यक्रम में स्पष्ट रूप से नहीं लिखा जा सकता है। क्लोजर में हेरफेर करने के लिए, एक प्रकार Fn है। इसमें तर्कों के प्रकार और वापसी मूल्य के साथ एक फ़ंक्शन हस्ताक्षर शामिल है, हालांकि, उन्हें व्यक्तिगत रूप से निकालना इतना आसान नहीं है।

मुख्य विचार निम्नलिखित फॉर्म की एक सहायक संरचना का उपयोग करना है:

 ///       F: Fn(A) -> B. struct SimpleExtractor<A, B, F> {   //   .   inner: F,   _a: PhantomData<A>,   _b: PhantomData<B>, } 

हम फैंटमडाटा का उपयोग करने के लिए मजबूर हैं क्योंकि जंग को संरचना की परिभाषा में सभी सामान्यीकरण मापदंडों की आवश्यकता होती है। हालाँकि, विशिष्ट प्रकार के क्लोजर या फंक्शन F का सामान्यीकरण नहीं किया जाता है (हालाँकि यह सामान्यीकृत Fn को लागू करता है)। टाइप ए और बी का उपयोग सीधे तौर पर नहीं किया जाता है।

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

 impl<A, B, F> Endpoint for F where F: Fn(&Context, A) -> B { type Request = A; type Response = B; fn handle(&self, context: &Context, request: A) -> Result<B, io::Error> { // ... } } 

इस मामले में संकलक एक त्रुटि देता है:

 error[E0207]: the type parameter `A` is not constrained by the impl trait, self type, or predicates --> src/main.rs:10:6 | 10 | impl<A, B, F> Endpoint for F where F: Fn(&Context, A) -> B { | ^ unconstrained type parameter 

SimpleExtractor की सहायक संरचना परिवर्तन से वर्णन करना संभव बनाती है। यह आपको किसी भी फ़ंक्शन को सहेजने और इसके तर्कों को निकालने की अनुमति देता है:

 impl<A, B, F> From<F> for SimpleExtractor<A, B, F> where F: Fn(&Context, A) -> B, A: DeserializeOwned, B: Serialize, { fn from(inner: F) -> Self { SimpleExtractor { inner, _a: PhantomData, _b: PhantomData, } } } 

निम्नलिखित कोड सफलतापूर्वक संकलित करता है:

 #[derive(Deserialize)] struct Query { a: i32, b: String, }; //   . fn my_handler(_: &Context, q: Query) -> String { format!("{} has {} apples.", qb, qa) } let fn_extractor = SimpleExtractor::from(my_handler); //  . let c = 15; let my_closure = |_: &Context, q: Query| -> String { format!("{} has {} apples, but Alice has {}", qb, qa, c) }; let closure_extractor = SimpleExtractor::from(my_closure); 

विशेषज्ञता और मार्कर प्रकार

अब हमारे पास स्पष्ट रूप से पैरामीटर किए गए तर्क प्रकारों के साथ एक फ़ंक्शन है, जो एंडपॉइंट विशेषता के स्थान पर उपयोग के लिए उपयुक्त है। उदाहरण के लिए, हम SimpleExtractor से RequestHandler में रूपांतरण को आसानी से लागू कर सकते हैं। लेकिन फिर भी, यह एक पूर्ण समाधान नहीं है। हमें किसी प्रकार के स्तर पर GET अनुरोध हैंडलर और POST अनुरोधों के बीच अंतर करने की आवश्यकता है (और अतुल्यकालिक लोगों से सिंक्रोनस हैंडलर)। तथाकथित मार्कर प्रकार हमें इसके साथ मदद करेंगे।

सबसे पहले, हम SimpleExtractor को फिर से लिखते हैं ताकि यह तुल्यकालिक और अतुल्यकालिक परिणामों के बीच अंतर कर सके। उसी समय, हम प्रत्येक मामलों के लिए फ्रिट विशेषता से लागू करते हैं। ध्यान दें कि लक्षण सामान्यीकृत संरचनाओं के विशिष्ट वेरिएंट के लिए लागू किए जा सकते हैं।

 ///   HTTP-. pub struct With<Q, I, R, F> { ///  -. pub handler: F, ///     . _query_type: PhantomData<Q>, ///   . _item_type: PhantomData<I>, ///  ,  . ///  ,       . _result_type: PhantomData<R>, } //   ,   . impl<Q, I, F> From<F> for With<Q, I, Result<I>, F> where F: Fn(&ServiceApiState, Q) -> Result<I>, { fn from(handler: F) -> Self { Self { handler, _query_type: PhantomData, _item_type: PhantomData, _result_type: PhantomData, } } } //     . impl<Q, I, F> From<F> for With<Q, I, FutureResult<I>, F> where F: Fn(&ServiceApiState, Q) -> FutureResult<I>, { fn from(handler: F) -> Self { Self { handler, _query_type: PhantomData, _item_type: PhantomData, _result_type: PhantomData, } } } 

अब हमें एक ऐसी संरचना घोषित करने की आवश्यकता है जिसमें अनुरोधकर्ता को उसके नाम और विविधता के साथ जोड़ा जा सके:

 #[derive(Debug)] pub struct NamedWith<Q, I, R, F, K> {   ///  .   pub name: String,   ///    .   pub inner: With<Q, I, R, F>,   ///  .   _kind: PhantomData<K>, } 

के बाद आप कई खाली संरचनाओं की घोषणा कर सकते हैं जो मार्कर प्रकारों के रूप में कार्य करेंगे। मार्कर आपको पहले से वर्णित RequestHandler के लिए अपने स्वयं के रूपांतरण कोड में से प्रत्येक के लिए कार्यान्वित करने की अनुमति देते हैं।

 /// ,    .  HTTP   GET-. pub struct Immutable; /// ,   .  HTTP   POST, PUT, UPDATE ///    ,        POST. pub struct Mutable; 

अब हम R और K टेम्प्लेट पैरामीटर के सभी संयोजनों के लिए प्रकार के चार अलग-अलग कार्यान्वयनों को परिभाषित कर सकते हैं (हैंडलर का अनुरोध मान और अनुरोध का प्रकार)।

 //     get . impl<Q, I, F> From<NamedWith<Q, I, Result<I>, F, Immutable>> for RequestHandler where F: Fn(&ServiceApiState, Q) -> Result<I> + 'static + Send + Sync + Clone, Q: DeserializeOwned + 'static, I: Serialize + 'static, { fn from(f: NamedWith<Q, I, Result<I>, F, Immutable>) -> Self { let handler = f.inner.handler; let index = move |request: HttpRequest| -> FutureResponse { let context = request.state(); let future = Query::from_request(&request, &()) .map(|query: Query<Q>| query.into_inner()) .and_then(|query| handler(context, query).map_err(From::from)) .and_then(|value| Ok(HttpResponse::Ok().json(value))) .into_future(); Box::new(future) }; Self { name: f.name, method: actix_web::http::Method::GET, inner: Arc::from(index) as Arc<RawHandler>, } } } //     post . impl<Q, I, F> From<NamedWith<Q, I, Result<I>, F, Mutable>> for RequestHandler where F: Fn(&ServiceApiState, Q) -> Result<I> + 'static + Send + Sync + Clone, Q: DeserializeOwned + 'static, I: Serialize + 'static, { fn from(f: NamedWith<Q, I, Result<I>, F, Mutable>) -> Self { let handler = f.inner.handler; let index = move |request: HttpRequest| -> FutureResponse { let handler = handler.clone(); let context = request.state().clone(); request .json() .from_err() .and_then(move |query: Q| { handler(&context, query) .map(|value| HttpResponse::Ok().json(value)) .map_err(From::from) }) .responder() }; Self { name: f.name, method: actix_web::http::Method::POST, inner: Arc::from(index) as Arc<RawHandler>, } } } //     get . impl<Q, I, F> From<NamedWith<Q, I, FutureResult<I>, F, Immutable>> for RequestHandler where F: Fn(&ServiceApiState, Q) -> FutureResult<I> + 'static + Clone + Send + Sync, Q: DeserializeOwned + 'static, I: Serialize + 'static, { fn from(f: NamedWith<Q, I, FutureResult<I>, F, Immutable>) -> Self { let handler = f.inner.handler; let index = move |request: HttpRequest| -> FutureResponse { let context = request.state().clone(); let handler = handler.clone(); Query::from_request(&request, &()) .map(move |query: Query<Q>| query.into_inner()) .into_future() .and_then(move |query| handler(&context, query).map_err(From::from)) .map(|value| HttpResponse::Ok().json(value)) .responder() }; Self { name: f.name, method: actix_web::http::Method::GET, inner: Arc::from(index) as Arc<RawHandler>, } } } //     post . impl<Q, I, F> From<NamedWith<Q, I, FutureResult<I>, F, Mutable>> for RequestHandler where F: Fn(&ServiceApiState, Q) -> FutureResult<I> + 'static + Clone + Send + Sync, Q: DeserializeOwned + 'static, I: Serialize + 'static, { fn from(f: NamedWith<Q, I, FutureResult<I>, F, Mutable>) -> Self { let handler = f.inner.handler; let index = move |request: HttpRequest| -> FutureResponse { let handler = handler.clone(); let context = request.state().clone(); request .json() .from_err() .and_then(move |query: Q| { handler(&context, query) .map(|value| HttpResponse::Ok().json(value)) .map_err(From::from) }) .responder() }; Self { name: f.name, method: actix_web::http::Method::POST, inner: Arc::from(index) as Arc<RawHandler>, } } } 

बैकएंड के लिए "मुखौटा"

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

 pub struct ServiceApiScope { actix_backend: actix::ApiBuilder, } impl ServiceApiScope { ///    Immutable    . pub fn endpoint<Q, I, R, F, E>(&mut self, name: &'static str, endpoint: E) -> &mut Self where //     ,      : Q: DeserializeOwned + 'static, I: Serialize + 'static, F: Fn(&ServiceApiState, Q) -> R + 'static + Clone, E: Into<With<Q, I, R, F>>, //  ,          //  NamedWith  RequestHandler. RequestHandler: From<NamedWith<Q, I, R, F, Immutable>>, { self.actix_backend.endpoint(name, endpoint); self } ///    Mutable . pub fn endpoint_mut<Q, I, R, F, E>(&mut self, name: &'static str, endpoint: E) -> &mut Self where Q: DeserializeOwned + 'static, I: Serialize + 'static, F: Fn(&ServiceApiState, Q) -> R + 'static + Clone, E: Into<With<Q, I, R, F>>, RequestHandler: From<NamedWith<Q, I, R, F, Mutable>>, { self.actix_backend.endpoint_mut(name, endpoint); self } 

ध्यान दें कि अनुरोध पैरामीटर के प्रकार, इसके परिणाम के प्रकार, साथ ही हैंडलर की समकालिकता / अतुल्यकालिकता अपने हस्ताक्षर से स्वचालित रूप से प्राप्त होती है। इसके अतिरिक्त, आपको अनुरोध के नाम के साथ-साथ इसके प्रकार को भी स्पष्ट रूप से निर्दिष्ट करना होगा।

दृष्टिकोण का नुकसान

इस दृष्टिकोण में अभी भी कमियां हैं। विशेष रूप से, एंडपॉइंट और एंडपॉइंट_मुट को विशिष्ट बैकएंड को लागू करने की बारीकियों को जानना चाहिए । यह हमें मक्खी पर बैकएंड जोड़ने की अनुमति नहीं देता है, लेकिन ऐसी कार्यक्षमता की शायद ही कभी आवश्यकता होती है।

एक और समस्या यह है कि आप अतिरिक्त तर्क के बिना किसी हैंडलर के लिए विशेषज्ञता को परिभाषित नहीं कर सकते। दूसरे शब्दों में, यदि हम निम्नलिखित कोड लिखते हैं, तो यह संकलन नहीं करेगा, क्योंकि यह मौजूदा सामान्यीकृत कार्यान्वयन के साथ संघर्ष करता है:

 impl<(), I, F> From<F> for With<(), I, Result<I>, F> where F: Fn(&ServiceApiState) -> Result<I>, { fn from(handler: F) -> Self { Self { handler, _query_type: PhantomData, _item_type: PhantomData, _result_type: PhantomData, } } } 

परिणामस्वरूप, जिन अनुरोधों का कोई मापदण्ड नहीं है, उन्हें अभी भी अशक्त JSON स्ट्रिंग को स्वीकार करना चाहिए, जो कि () के लिए डिस्अरीलाइज़्ड है। इस समस्या को C ++ की शैली में विशेषज्ञता द्वारा हल किया जा सकता है, लेकिन अभी तक यह केवल संकलक के रात के संस्करण में उपलब्ध है और यह "स्थिर" होने पर अस्पष्ट है।

इसी तरह, आप रिटर्न वैल्यू के प्रकार के विशेषज्ञ नहीं हो सकते। यहां तक ​​कि अगर अनुरोध इसे लागू नहीं करता है, तो यह हमेशा JSON को शून्य के साथ लौटाएगा।

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

निष्कर्ष

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