मैं एक ज़ेंड फ्रेमवर्क आधारित एप्लिकेशन विकसित कर रहा हूं और मैंने खुद को एपीआई मॉड्यूल के लिए कंकाल लिखना पाया। मैंने वेब पर थोड़ा सा पढ़ा और मैंने Zend_Rest_Controller पर आधारित कंकाल लिखना शुरू कर दिया। ठीक है, एपीआई का उपयोग करने के लिए आवश्यक कुंजी लॉगिन।रीस्टफुल ज़ेंड फ्रेमवर्क एपीआई
प्रश्न तब शुरू हुए जब मेरे एक सहयोगी ने हमारे अनुप्रयोगों में से एक के लिए एक उचित एपीआई में कंकाल को लागू करना शुरू किया। उसने मुझे बताया कि वह सोचता है कि यह बेहतर होगा अगर हमारे पास केवल एक सामान्य Zend_Controller_Action एपीआई नियंत्रक में विस्तारित किया गया था और indexActionZend_Rest_Server में ऑब्जेक्ट को संभालता है।
मैं इसके बारे में थोड़ा उलझन में हूं। मेरे व्यक्तिगत दृष्टिकोण से मैं एक "बड़े से अधिक औसत" नियंत्रक रखना चाहता हूं जिसमें प्रत्येक 4 क्रियाओं (प्राप्त करें, पोस्ट करें, हटाएं, हटाएं) और प्रत्येक क्रिया में कुछ तर्क शामिल हैं, Zend_Rest_Server।
मेरी समस्या यह है कि मैं नहीं समझ सकता कि 2 समाधानों में से कौन सा समाधान आर्किटेक्चर बिंदु से बेहतर है; और निश्चित रूप से, समय के साथ सबसे आसानी से रखरखाव योग्य।
मैं देख रहा हूँ पर एक नज़र डालें सुझाव है कि आप Zend पर बाकी काम करना चाहते हैं। यह दिलचस्प हो रहा है ... 'Zend_Rest_Controller' के साथ मामूली समस्या यह है कि आप अपने आप को बल्कि वसा नियंत्रक पाएंगे, दूसरा समाधान एपीआई के माध्यम से उजागर करने वाली वस्तु के लिए सेवा ऑब्जेक्ट बना रहा है। और यह rest_controller-> object_service-> ऑब्जेक्ट-> object_model-> eventual_object_custom_abstraction में अनुवाद करेगा जो मुझे लगता है कि बिना किसी अध्ययन में टीम को बनाए रखने के लिए काफी कठिन है, आपको शेष नियंत्रक –
में अंतिम ऑब्जेक्ट का प्रतिनिधित्व कैसे मिलता है आपके कार्यान्वयन का विवरण हैं वास्तव में आपके डोमेन पर निर्भर है, लेकिन ऐसा लगता है कि आप सही रास्ते पर हैं, आम तौर पर बोलते हैं। मुझे यकीन नहीं है कि आपकी प्रत्येक परत में क्या है, लेकिन जब मैं इस तरह की चीज करता हूं, तो मेरे नियंत्रक एक सेवा परत पर भरोसा करते हैं जो डोमेन ऑब्जेक्ट्स में हेरफेर करता है, और कुछ प्रकार की दृढ़ता परत के माध्यम से स्टोर/लांचिंग को संभालता है। – timdev