एपीआई एक वेबसाइट और मोबाइल ऐप के लिए कोर के रूप में

Question

मेरे पास एक पूर्ण आर्किटेक्चर विचार के बारे में अलग-अलग प्रश्न हैं। मुझे आशा है कि महान अनुभव वाला कोई व्यक्ति मेरी मदद कर सकता है क्योंकि मैं सभी संभावनाओं में फंस गया हूं।

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

पहले एपीआई निजी होगा, लेकिन बाद में हम इसे अधिक आसानी से कनेक्ट करने के लिए सार्वजनिक कर सकते हैं।

डी बुनियादी बाकी संरचना इस प्रकार है:

1. /बिल्लियों
2. /बिल्लियों/1
3. /बिल्लियों/1/कस्टम

'कस्टम' हो सकता है 'बच्चे' उदाहरण के लिए।

ही चला जाता है के लिए:

1. /विज्ञापन
2. /बोलियों
3. /उपयोगकर्ताओं
4. /बैनर
5. आदि ..

एपीआई के लिए ये हैं सही संस्थाओं क्योंकि मोबाइल ऐप निश्चित रूप से इस कार्यक्षमता का उपयोग करेगा।

तो हम निष्कर्ष निकाल सकते हैं कि वेबसाइट का मूल REST है। इसलिए मूल रूप से मैं वेबसाइट को भविष्य में मूल ऐप की तरह एपीआई का क्लाइंट बनाना चाहता हूं। इस तरह रखरखाव बहुत आसान लगता है।

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

मैं निम्नलिखित मॉड्यूल बनाने के बारे में सोचा:

1. समुदाय-api
2. समुदाय वेबसाइट

API मुख्य तो हो रहा है। लेकिन .... cronjobs आदि के बारे में क्या? दरअसल वे वेबसाइट का हिस्सा नहीं बनना चाहिए, क्योंकि यह सिर्फ 'ग्राहक' है। मुझे लगता है कि उन्हें सीधे मॉडल या एपीआई के साथ बातचीत करनी चाहिए।तो मूल रूप से एपीआई अधिक कोर लिए एक प्रवेश द्वार की तरह हो जाता है और मैं इस की जरूरत है सोचा:

1. समुदाय कोर
   • मॉडल
   • cronjobs
   • ऑटो चिट्ठियाँ (cronjobs का हिस्सा)
     • चालान आदि
2. समुदाय-api
   • HTTP
3. समुदाय वेबसाइट
   • वेबसाइट
   • व्यवस्थापक

कोर cronjob के माध्यम से कोर में मॉडलों के साथ सहभागिता एसईएसटी संरचना के लिए अपवाद हैं। वे अकेले हैं जो एपीआई के बिना डेटा बदल सकते हैं। कम से कम यह मेरा विचार था क्योंकि वे कोर में हैं और एपीआई कोर के शीर्ष पर है।

लेकिन डिज़ाइन द्वारा जो कि गलत लगता है। मैनिपुलेटिंग केवल एपीआई के माध्यम से जाना चाहिए!

वैकल्पिक:

1. समुदाय कोर
   • मॉडल
2. समुदाय-api
   • HTTP के माध्यम से कोर में मॉडलों के साथ सहभागिता
3. समुदाय व्यापार
   • cronjobs
   • ऑटो चिट्ठियाँ (cronjobs का हिस्सा)
     • चालान आदि
4. समुदाय वेबसाइट
   • वेबसाइट
   • व्यवस्थापक

यह मेरे लिए डिजाइन द्वारा बेहतर दिखती हैं। Mindmap illustration http://mauserrifle.nl/mindmap.jpg

मुख्य प्रश्न

1)

एपीआई या कोर मॉडलों के माध्यम से हेरफेर cronjobs चाहिए?

2)

मेरे चालान cronjob एक टेम्पलेट काफी निश्चित रूप से मुख्य वेबसाइट की शैली की जरूरत है। लेकिन अगर मेरा क्रोनबॉज व्यवसाय या कोर का हिस्सा है तो उसे मेरी मुख्य वेबसाइट का ज्ञान नहीं होगा। इसे हल करने के लिए क्या समझ में आता है?

3)

मेरी वेबसाइट में एक टेम्पलेट इंजन के रूप में मूंछ का उपयोग किया जाएगा। (दोनों PHP और जावास्क्रिप्ट इन टेम्पलेट्स को पार्स कर सकते हैं)। मैंने एजेक्स कॉल के लिए सीधे एपीआई का उपयोग करने का सोचा लेकिन फिर एहसास हुआ:

साइट एपीआई से डेटा प्राप्त करती है, टेम्पलेट के लिए दिनांक टाइममैंप (वाई-एम-डी) स्वरूपित करती है और फिर प्रस्तुत करती है। अगर मैंने जावास्क्रिप्ट को सीधे एपीआई कॉल करने दिया है, तो जावास्क्रिप्ट में भी तर्क होना चाहिए (स्वरूपण)। यह डुप्लिकेट कोड है! ऐसा लगता है कि एकमात्र समाधान वेबसाइट को AJAX के लिए बुला रहा है (जो एपीआई और प्रारूपों को कॉल करता है) और स्वरूपित जेसन लौटाता है। क्या मैं सही हू?

लेकिन .... एक विज्ञापन API सीधे के माध्यम से जा सकते हैं हटाने जैसे सरल कॉल (जैसे हटाएँ:/विज्ञापन/1

मैं कॉल का मिश्रण मिलता है ....

किसी भी बेहतर समाधान इस के लिए

4)

कुल मिलाकर: मेरी वास्तुकला बहुत जटिल है? मुझे किसी भी विकल्प पर विचार करना चाहिए?

मुझे आपकी प्रतिक्रिया सुनना अच्छा लगेगा!

Answer 1

एक बार मैंने सुना है कि एक वेब अनुप्रयोग विकसित करने का एक अच्छा तरीका API-Centric Web Application विकसित करना है। बात यह है कि, यदि आप सार्वजनिक एपीआई की मुख्य सेवा को जोड़ते हैं, तो एक एपीआई-केंद्रित आवेदन बनाते हैं, तो आप एक सार्वजनिक एपीआई विकसित करने का पूरा बिंदु खो देते हैं।

Answer 2

यह मेरे लिए तार्किक प्रतीत नहीं होता है।

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

सार्वजनिक एपीआई के लिए, यदि संभव हो तो एक ही डोमेन कक्षाओं का पुन: उपयोग करना संभव है, लेकिन अलग-अलग प्रमाणीकरण विधियों के साथ, जो भी समस्या हो सकती है, यह मुख्य सेवा को प्रभावित नहीं करेगा।

आपका क्रॉन-नौकरियों केवल, दोहरा-खुद बिना एपीआई खुद के माध्यम से कॉल आग इस्तेमाल किया जाना चाहिए और इन कॉल के मुख्य अनुप्रयोग (एपीआई के माध्यम से वेबसाइट)

आप अपनी वेबसाइट का निर्माण तो पर किया जाना चाहिए जैसा कि, आधार के समान कोड का उपयोग करके और इसके आस-पास वेब-एप लपेटकर, आपके पास q # 2 में समस्या बढ़ाना नहीं होगा।

वही बात प्रश्न संख्या 3 के लिए लागू होती है। यदि आप एपीआई के आसपास वेबसाइट को लपेटते हैं, तो वेबसाइट एक अलग इकाई के बिना एपीआई का उपयोग कर सकती है।

आपका आर्किटेक्चर जटिल लगता है लेकिन यदि आप इन चीजों को करते हैं, तो यह आसान होगा।;-)

शुभकामनाएं!

Answer 3

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