REST API को लागू करने के लिए ऑब्जेक्ट्स को json फॉर्मेट में सीरियलाइज़ करना

सिम्फनी 2.1 जारी होने वाली है, और समुदाय अभी भी बैसाखी के बिना पूर्ण रीस्ट को लागू नहीं कर सकता है, और, मेरी राय में, यहां कुछ गलत है। हाल ही में, एक लेख जोर से शीर्षक REST API के साथ Symfony2: द राइट वे के साथ प्रकाशित किया गया था, लेकिन, संक्षेप में, यह केवल मेरे शब्दों की पुष्टि करता है। संपूर्ण समस्या वस्तुओं के क्रमांकन और विचलन में रहती है। ऐसा लगता है कि सबसे सरल कार्य और समाधान कई होने चाहिए, लेकिन, दुर्भाग्य से, नहीं। चलो सब कुछ क्रम में बात करते हैं।

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

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

दूसरी समस्या अशक्त मूल्यों को क्रमबद्ध करने में असमर्थता है। हमारे बाकी एपीआई के संबंध में - यह अस्वीकार्य है। बहुत बड़ा मुद्दा है , लेकिन मुझे यकीन है कि समाधान नहीं होगा। वास्तव में, स्थिति बहुत अजीब है। यदि आप json_decode और json_encode लेते हैं, तो वे इस कार्य को सही ढंग से संभालते हैं। एक्सएमएल प्रारूप के लिए, मैंने एक साल पहले इस समस्या को हल किया था जब सिद्धांत-ऑक्सम को लागू किया गया था।

तीसरी समस्या एक मौजूदा डेटा ऑब्जेक्ट में डीसर्विलाइज़ करने में असमर्थता है। इससे आंशिक डेटा अपडेट करने वाले POST / PATCH अनुरोधों का उपयोग करना असंभव हो जाता है। मुख्य प्रश्न यह है कि सिम्फनी 2 में REST के आसान कार्यान्वयन के बारे में FOSRestBundle लोगों को कैसे बेवकूफ बना रहा है।

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

तो, ऐसा लगता है कि खुशी पहले से ही निकट है, और हम अपने मॉडल को अपडेट कर सकते हैं। कोई फर्क नहीं पड़ता कि यह कितना कठिन है, हम अपनी इच्छा के खिलाफ जाने और अपनी डीटीओ (डेटा ट्रांसफर ऑब्जेक्ट) ऑब्जेक्ट के लिए फॉर्मटाइप बनाने के लिए तैयार हैं, पूरी तरह से JMSSerializerBundle को SimpleThingsFormSerializerBundle से बदल दें। उन्होंने ऐसा किया, लेकिन उन्हें खुशी नहीं मिली। जैसा कि यह निकला, नया बंडल सभी सूचनाओं को तार में परिवर्तित करता है, अर्थात। हमारे क्लाइंट को कभी भी संख्यात्मक या बूलियन मान दिखाई नहीं देंगे। हमें इस सवाल का जवाब नहीं मिला कि ऐसा क्यों किया गया था, जेएमएस सेरियलाइज़र का उपयोग करने के लिए क्रमांकन के लिए केवल प्रस्‍तावना के लिए एक प्रस्‍ताव था - फॉर्मलाइज़र। लेकिन मुझे लगता है कि यहां कुछ गलत है। इसके अलावा, संस्करण 2.0 में सिम्फनी फॉर्म केवल GET या POST अनुरोधों के साथ बाइंड कर सकता है, बाकी को अनदेखा कर सकता है। हां, और मेरे पास REST के लिए प्रपत्रों के उपयोग के बारे में बहुत सारे "फाई" हैं, इसे लेख के दायरे से बाहर छोड़ दें। मैं दो हफ्ते के लिए इस उम्मीद से छुट्टी पर गया था कि कुछ बदल जाएगा। लेकिन ...

कार्य सरल लगता है, हमारे REST API में हमें json फॉर्मेट में जानकारी देने की गारंटी दी जाती है। अन्य प्रारूप हमें दिलचस्पी नहीं लेते हैं (यह मुझे लगता है, अधिकांश आधुनिक परियोजनाओं की तरह)। हम मानते हैं कि हमारे पास डीटीओ ऑब्जेक्ट हैं जो हमेशा अपनी विशेषताओं के लिए सेट / प्राप्त करते हैं। हम इन डीटीओ को जेसन और बैक में बदलना चाहते हैं (ऊपर वर्णित समस्याओं के समाधान के साथ)। हम वास्तव में yml प्रारूप में और JMSSerializerBundle सेटिंग्स की पूरी विविधता से क्रमबद्ध नियमों को संग्रहीत करने की क्षमता पसंद करते हैं, हमें केवल फ़ील्ड की मैपिंग ("क्रमबद्ध_नाम" और "प्रकार") और ध्वज को निर्दिष्ट करने की आवश्यकता है "एक्सपोज़"।

अपने पुस्तकालय के कार्यान्वयन से आगे बढ़ने से पहले, मैंने एक बार फिर वर्तमान समाधानों की खोज की। दो दिलचस्प परियोजनाएं मिलीं:
FbsSerializer - जैसा कि मुझे लगता है, JMSSerializerBundle का "पूर्ववर्ती"। कार्यान्वयन के लिए संभावनाएं और विचार बहुत समान हैं, समान समस्याएं मौजूद हैं, और अनुचित रूप से संग्रह को क्रमबद्ध भी करती हैं;
ObjectSerializer एक बहुत ही सरल कार्यान्वयन है, यह लगभग मेरे पुस्तकालय को देखने के तरीके से मेल खाता है। मुख्य दोष यह है कि क्लास मैपिंग को कंस्ट्रक्टर के माध्यम से पारित किया जाता है, जो हमारे लिए अस्वीकार्य है।

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

<?php class Serializer { public function serialize($object) { $array = $this->arrayAdapter->toArray($object); return $this->adapter->serialize($array); } public function unserialize($data, $object) { $array = $this->serializerAdapter->unserialize($data); return $this->arrayAdapter->toObject($array, $object); } } ?> 

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

serializerAdapter हमारे मामले में json_encode, json_decode फ़ंक्शन पर एक साधारण आवरण का प्रतिनिधित्व करता है। हमारे द्वारा तर्क किए गए सभी तर्क ArrayAdapter में हैं। यहां हम इस लाइब्रेरी के कॉन्फ़िगरेशन डेटा और क्रमांकन और JbsSerializerBundle के वैचारिक अंतर में वैचारिक अंतर पाते हैं।

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

 <?php class ArrayAdapter { public function toArray($object) { $result = array(); $className = $this->getFullClassName($object); $metadata = $this->metadataFactory->getMetadataForClass($className); foreach ($metadata->getProperties() as $property) { //handle value $result[$property->getSerializedName()] = $value; } return $result; } public function toObject(array $data, $object) { $className = $this->getFullClassName($object); $metadata = $this->metadataFactory->getMetadataForClass($className); foreach ($metadata->getProperties() as $property) { //handle value and set it to object } return $object; } } ?> 

क्रमांकन / deserialization के मूल्यों को संसाधित करने के लिए, हम वर्तमान में निजी हैंडल विधि (लगभग 60 लाइनें) का उपयोग करते हैं।

प्रारंभ में, एक yml फ़ाइल से किसी ऑब्जेक्ट में सेटिंग्स बदलने के लिए, मैं अपना खुद का कुछ लिखना चाहता था, क्योंकि कार्य बहुत सरल है। आपको दो चीजों से सार करने की आवश्यकता है: कॉन्फ़िगरेशन फ़ाइलों का स्थान (वे कहीं भी संग्रहीत किए जा सकते हैं: फ़ाइल सिस्टम, मेमोरी, डेटाबेस) और उनका प्रारूप (yml, json, ini, xml)। उसी समय, जैसा कि टीम लीडर ने नोट किया, "हम हर बार * .yml फ़ाइल को पार्स नहीं करेंगे", इसलिए हमें कैश की आवश्यकता है। इसका इंटरफ़ेस सभी के लिए जाना जाता है: पुट, गेट, रिमूव। लेकिन मैं समय पर रुक गया और मेटाडेटा लाइब्रेरी को याद किया, और फिर से उस प्रतिबिंब में भाग गया जिसकी मुझे आवश्यकता नहीं थी। इसलिए, मामूली सुधार के साथ, कोड का यह हिस्सा वहां से लिया गया था, जोहान्स को सलाम करता था।

नतीजतन, मैं टीम के लिए 33 घंटे के लिए खो गया था, लेकिन सरल- सीरीकेज़र लाइब्रेरी और ओपन्सॉफ्टसिमप्लेसेरियलाइज़र बंडल बंडल लिखा गया था ।

लाइब्रेरी निर्भरताएँ:
सिम्फनी / yaml घटक

आवश्यकताएँ:
- एक अनुक्रमिक वस्तु के लिए, क्रमांकन नियमों का वर्णन किया जाना चाहिए;
- क्रमबद्ध करने योग्य वस्तु में विशेषताओं के लिए बसने और पाने वाले होने चाहिए।

JMSSerializerBundle की तुलना में लाभ:
- इसमें कई तरह की समस्याएँ नहीं हैं, जैसे: एक शून्य मान के साथ प्रसंस्करण विशेषताएँ, मौजूदा ऑब्जेक्ट में डेटा को डीरियलाइज़ करना;
- कॉन्फ़िगरेशन में दिनांक स्वरूपण की स्थापना;
- सिम्फनी 2 ढांचे के लिए एक बंधन नहीं है।

स्वाभाविक रूप से, यह आदर्श नहीं है। JMSSerializerBundle अधिक कार्यात्मक है और इसमें कम प्रतिबंध हैं। लेकिन, हमारे मामले में, रीस्ट एपीआई के कार्यान्वयन में उपयोग के लिए एक स्पष्ट पूर्वाग्रह है। जब हम बड़े अनुप्रयोगों में आरईएसटी से निपटते हैं, तो हम डीटीओ पैटर्न को लागू किए बिना नहीं कर सकते हैं, क्योंकि हमारे मॉडल एपीआई में स्पष्ट रूप से प्रतिबिंबित नहीं होंगे। और, तदनुसार, असेंबलर डीटीओ को डोमेनऑबजेक्ट में कनवर्ट करते समय सबसे अधिक संभावना सेटर / गेट्टर विधियों का उपयोग करेगा। और दूसरी आवश्यकता अपने आप गायब हो जाती है। पहला, मुझे लगता है, सब कुछ भी करता है। आखिरकार, ग्राहकों को एपीआई प्रदान करके, हम उन्हें बताते हैं कि हम क्या और किस प्रारूप में स्वीकार करते हैं या देते हैं। और यह अतार्किक लगता है अगर हमारे पास ये नियम नहीं हैं। विभिन्न प्रारूपों में प्रतिक्रिया के लिए, हम अपनी परियोजना में जसन के साथ काम कर रहे हैं। यह बहुत ही सरल और सुविधाजनक है। XML, मेरी राय में, पहले से ही REST में उपयोग के लिए थोड़ा पुराना है। FOSRestBundle द्वारा प्रदान किया जाने वाला HTML प्रारूप बहुत दूर की कौड़ी है, मैं इसके उपयोग की कल्पना नहीं कर सकता। व्यवहार परीक्षण REST API की विश्वसनीयता के लिए जिम्मेदार हैं (हेलो और कोंस्टेंटिन उर्फ एवरजेट के लिए धन्यवाद), मुझे उम्मीद है कि डायवर्ट नाराज नहीं होगा, क्योंकि कोडलाइट वास्तव में अच्छा है।

यह क्रमबद्धता को कॉन्फ़िगर करने की संभावना के बारे में अलग से बात करने लायक है। विकल्प कम से कम हैं, हालांकि उन्हें पूरक करना बिल्कुल भी मुश्किल नहीं है। कॉन्फ़िगरेशन फ़ाइल आमतौर पर JMSSerializerBundle के समान होती है:

 MyBundle\Model\Order properties: id: expose: true serialized_name: id type: integer 

"एक्सपोज़" विकल्प "झूठे" को डिफॉल्ट करता है, इसलिए उन सभी विशेषताओं के लिए जिन्हें हम क्रमबद्ध करना चाहते हैं, आपको इसे निर्दिष्ट करना होगा। यह मेरी व्यक्तिगत प्राथमिकता है, जो अनुमति नहीं है वह निषिद्ध है। शायद उनकी युवावस्था में एसीएल का प्रभाव। सिद्धांत रूप में, यदि आप चाहें तो आप एक पूर्ण बहिष्कृत / निष्कासन लागू कर सकते हैं। Serialized_name एक वैकल्पिक पैरामीटर है, यदि यह निर्दिष्ट नहीं है, तो विशेषता को उसके नाम के अनुसार क्रमबद्ध किया जाएगा। अंतिम "प्रकार" विकल्प भी वैकल्पिक है। यदि यह निर्दिष्ट नहीं है, तो विशेषता मान के साथ कोई कार्रवाई नहीं की जाएगी। अन्यथा, यह निर्दिष्ट प्रकार के लिए डाला जाएगा। संभव प्रकार: पूर्णांक, बूलियन, डबल, स्ट्रिंग, सरणी, टी, सरणी <टी>, दिनांक समय, दिनांक समय <प्रारूप>।
JMSSerializerBundle से मुख्य अंतर एक ArrayCollection की अनुपस्थिति और एक DateTime <प्रारूप> की उपस्थिति है। पहला अनुपस्थित रूप से अनुपस्थित है, क्योंकि इसकी उपस्थिति डॉक्ट्रिन / ऑरम पर एक पुस्तकालय निर्भरता जोड़ती है। यदि आप सिम्फनी 2 ढांचे का उपयोग करते हैं, तो 90% में संतुष्ट हो जाएगा। लेकिन अन्य 10 प्रतिशत के बारे में क्या, या जो लोग सिम्फनी का उपयोग नहीं करते हैं? इसके अलावा, अगर हम डीटीओ को आवेदन करने के बारे में बात कर रहे हैं, तो निश्चित रूप से लगभग कोई संग्रह नहीं होगा, वे कोई मतलब नहीं रखते हैं। लेकिन इस समस्या को भविष्य में हल किया जा सकता है। दूसरी विशेषता यह निर्दिष्ट करने की क्षमता है कि दिनांक को कैसे प्रारूपित किया जाए। याद रखें कि एक DateTime प्रविष्टि मानती है कि आपके पास DateTime ऑब्जेक्ट है। अगर मैं गलत नहीं हूँ, JMSSerializerBundle में आप एक कस्टम दिनांक हैंडलर बना सकते हैं और उसमें प्रारूप निर्दिष्ट कर सकते हैं। यहां सब कुछ सरल है, सीधे कॉन्फ़िगरेशन में आप डेटाइम क्लास के एक निरंतरता को निर्दिष्ट कर सकते हैं, उदाहरण के लिए, "ISO8601", या आवश्यक समय स्वरूपण के साथ एक स्ट्रिंग।

आप एक TODO सूची बना सकते हैं, हालांकि, ईमानदार होने के लिए, मैं इसे तत्काल आवश्यकता के रूप में नहीं देखता हूं:
1) अन्य स्वरूपों में क्रमांकन विन्यास (एनोटेशन, एक्सएमएल) को स्टोर करने की क्षमता जोड़ें;
2) json के अलावा अन्य स्वरूपों में डेटा को क्रमबद्ध करने की क्षमता जोड़ें;
3) कॉन्फ़िगरेशन के लिए विभिन्न प्रकार के विकल्प जोड़ें;
4) हैंडल में कोड को रिफ्लेक्टर करें, विजिटर, या चैन ऑफ रिस्पॉन्सिबिलिटी, या कुछ और को लागू करने, जिससे कस्टम वैल्यू हैंडलर बनाने की क्षमता बढ़े;
5) कुछ और।

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