371

बंद हो गया । यह प्रश्न राय आधारित है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि यह तथ्यों और उद्धरणों के साथ उत्तर दे सके इस पोस्ट संपादित ।

3 साल पहले बंद हुआ ।

मैं स्क्रैच से वेब ऐप्स का एक समूह बनाने वाला हूं। (देख ओवरव्यू के लिए http://50pop.com/code ।) मैं उनके लिए कई अलग-अलग क्लाइंट्स से एक्सेस होने में सक्षम होना चाहूंगा: फ्रंट-एंड वेबसाइट्स, स्मार्टफोन ऐप्स, बैकएंड वेबसर्विसेज इत्यादि। हर एक के लिए JSON रीस्ट एपीआई।

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

कृपया मुझे यह तय करने में मदद करें कि मुझे कौन सा दृष्टिकोण लेना चाहिए:

नाखूनों में चोट

एक बहुत ही मानक रेल वेब-ऐप बनाएं। नियंत्रक में, JSON या HTML की सेवा करने के लिए response_with स्विच करें। JSON की प्रतिक्रिया तब मेरा API है।

समर्थक: बहुत मिसाल। महान मानकों और इस तरह से काम करने के कई उदाहरण हैं।

कोन: जरूरी नहीं कि API वेब ऐप की तरह ही हो। पसंद नहीं है अगर / फिर response_with स्विच दृष्टिकोण। दो बहुत अलग चीजों को मिलाकर (UI + API)।

रेस्ट सर्वर्स + जावासिपेट-हेवी क्लिंट

JSON- केवल REST API सर्वर बनाएं। ब्राउज़र में टेम्प्लेट प्रदर्शित करते हुए सीधे एपीआई तक पहुंचने के लिए क्लाइंट-साइड जावास्क्रिप्ट के लिए बैकबोन या एम्बर.जेएस का उपयोग करें।

प्रो: मुझे एपीआई और क्लाइंट के अलगाव से प्यार है। स्मार्ट लोग कहते हैं कि यह रास्ता है। सिद्धांत रूप में महान। अत्याधुनिक और रोमांचक लगता है।

Con: बहुत अधिक मिसाल नहीं। इसके कई उदाहरणों ने अच्छा नहीं किया। सार्वजनिक उदाहरण (twitter.com) सुस्त महसूस करते हैं और यहां तक कि इस दृष्टिकोण से दूर जा रहे हैं।

अन्य सर्वर + SERVER-SIDE HTML ग्राहक

JSON- केवल REST API सर्वर बनाएं। एक मूल HTML वेबसाइट क्लाइंट बनाएं, जो केवल REST API को एक्सेस करता है। कम क्लाइंट-साइड जावास्क्रिप्ट।

प्रो: मुझे एपीआई और क्लाइंट के अलगाव से प्यार है। लेकिन सादे HTML5 परोसना काफी मूर्खतापूर्ण है और क्लाइंट-सघन नहीं है।

Con: बहुत अधिक मिसाल नहीं। इसके कई उदाहरणों ने अच्छा नहीं किया। चौखटे भी इस का समर्थन नहीं करते। सुनिश्चित नहीं है कि यह कैसे संपर्क करे।

विशेष रूप से अनुभव से सलाह लेने के लिए, न केवल सिद्धांत में।

— Sivers
स्रोत

50

हम आम तौर पर पसंद करते हैं कि सट्टा, वैचारिक व्हाइटबोर्ड प्रश्न programmers.stackexchange.com पर चलते हैं जबकि स्टैक ओवरफ्लो पर यहाँ प्रश्न वास्तविक स्रोत कोड 99% होना चाहिए । लेकिन, यह एक अच्छी तरह से पूछा गया सवाल है और मुझे आपके काम से प्यार है, इसलिए यह अभी के लिए ग्रे क्षेत्र में गिर सकता है।

— जेफ एटवुड

2

क्या किसी के पास कुछ उदाहरण / स्रोत हैं (उनके कारणों को समझने के लिए) जो विकल्प 2 से दूर जा रहे हैं?

— विक्टर लोपेज गार्सिया

12

@frntk मूल कारण बहुत सी कंपनियाँ (जैसे ट्विटर) जावास्क्रिप्ट क्लाइंट कर रही थीं क्योंकि उन्हें लगा था कि यह तेजी से होगा। अब, वे महसूस कर रहे हैं कि यह वास्तव में धीमा है। देखें engineering.twitter.com/2012/05/... और openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering

— मोशे Katz

1

ऊपर दिए गए लिंक में टिप्पणी पढ़ें। लेख की कई धारणाएँ तर्क और अनुभव से मुकर जाती हैं।

— रिटिकलिन

1

इन दिनों आप jsonapi.org स्पेक्स के बाद JSON एपीआई बैकएंड बनाना चाहते हैं ... :)

— आस्कर

136

पर असीम , हम # 2 विकल्प के साथ गहरी चला गया और छात्रों के हजारों करने के लिए यह उपलब्ध कराई गई। हमारा सर्वर एक JSON REST API (Scala + MongoDB) है, और हमारे सभी क्लाइंट कोड को CloudFront से सीधे बाहर परोसा जाता है (यानी: www.boundless.com CloudFront के लिए सिर्फ एक उपनाम है)।

पेशेवरों:

अत्याधुनिक / रोमांचक
आपके हिरन के लिए बहुत सारे धमाके: एपीआई आपको अपने स्वयं के वेब क्लाइंट, मोबाइल क्लाइंट, तीसरे पक्ष की पहुंच आदि के लिए आधार देता है।
अत्यधिक तेज़ साइट लोडिंग / पृष्ठ संक्रमण

विपक्ष:

बहुत अधिक काम के बिना SEO के अनुकूल / तैयार नहीं।
टॉप-नॉट वेब फ्रंट-एंड लोक की आवश्यकता होती है जो किसी साइट के अनुभव की वास्तविकता का सामना करने के लिए तैयार होते हैं जो कि 70% जावास्क्रिप्ट है और इसका क्या मतलब है।

मुझे लगता है कि यह सभी वेब-ऐप्स का भविष्य है।

वेब फ्रंट एंड लोगों के लिए कुछ विचार (जो सभी नए-नेस / चुनौती को इस वास्तुकला को दिया गया है):

CoffeeScript। उच्च गुणवत्ता वाले कोड का उत्पादन करने के लिए बहुत आसान है।
रीड की हड्डी। अपने तर्क और सक्रिय समुदाय को व्यवस्थित करने का शानदार तरीका।
HAMLC। Haml + CoffeeScript टेम्पलेट्स => जेएस।
एस.ए.एस.एस.

हमने 'स्पार' (सिंगल पेज ऐप रॉकेटशिप) नामक हमारे फ्रंट-एंड डेवलपमेंट के लिए एक हार्नेस का निर्माण किया है जो प्रभावी रूप से सिंगल पेज ऐप डेवलपमेंट के लिए बनाए गए रेल से परिसंपत्ति पाइपलाइन है। हम अपने गिथब पर अगले कुछ हफ्तों के भीतर ओपन-सोर्सिंग करेंगे पृष्ठ , साथ ही साथ एक ब्लॉग पोस्ट के बारे में बताएंगे कि इसे और समग्र रूप से कैसे उपयोग किया जाए।

अपडेट करें:

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

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

— हारून
स्रोत

1

जोड़ने के लिए एक मामूली बिंदु: जबकि मैंने केवल # 1 विकल्प बनाया है, मैं कई मोबाइल ऐप डेवलपर्स को जानता हूं जो # 2 के लिए एक तेज़ पथ को सक्षम करने के लिए अपने बैकएंड के रूप में parse.com का उपयोग करना शुरू कर रहे हैं ।

— Rh123 १२

Parse और Kinvey जैसी चीजें बहुत दिलचस्प हैं, मैं नहीं कह सकता कि मुझे अभी तक w / उन्हें खेलने का मौका मिला है। निर्भर करता है कि आपका मान मेरे सामने वाले स्टैक के आगे या पीछे है

— हारून

मैं दृश्यपटल के लिए spinejs के साथ एक ही दृष्टिकोण का उपयोग करता हूं।

— निकोलस गोय

आप दो अलग-अलग एप्लिकेशन चलाने वाले एकल डोमेन को कैसे संभालते हैं? उदाहरण के लिए। मेरे पास www.mysite.com है और मैं एक सार्वजनिक एपीआई को उजागर करना चाहता हूं और उस URL पर फ्रंट-एंड की सेवा करना चाहता हूं। अन्य सिद्धांतों के अनुसार, वेब ब्राउज़र से mysite.com/product/24 एक्सेस किया गया HTTP HTTP हेडर देखकर एचटीएमएल पेज को वापस करना चाहिए, और mysite.com/product/24 पर एक्सेप्ट हेडर में JSON के साथ GET, JSON वापस करना चाहिए। ।

— एरच

इसके लिए एंगुलरजेएस कैसे पैन करेगा?

— अंकन-ज़ेरोब

48

बहुत अच्छा पूछा। +1। निश्चित रूप से, यह मेरे लिए भविष्य में उपयोगी संदर्भ है। इसके अलावा @Aaron और अन्य ने चर्चा में मूल्य जोड़ा। रूबी की तरह, यह प्रश्न अन्य प्रोग्रामिंग वातावरणों पर समान रूप से लागू है।

मैंने पहले दो विकल्पों का उपयोग किया है। कई अनुप्रयोगों के लिए पहला और मेरे ओपन सोर्स प्रोजेक्ट काउप के लिए दूसरा

विकल्प 1

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

विकल्प 2

मुझे यह हमेशा पसंद था।

यह विकल्प यह भी बताता है कि HTML सर्वर पर उत्पन्न रनटाइम नहीं है। यह कैसे विकल्प 2 विकल्प 3 से अलग है। लेकिन बिल्ड स्क्रिप्ट का उपयोग करके स्थिर HTML के रूप में बनाया जाता है। जब क्लाइंट साइड पर लोड किया जाता है तो ये HTML API सर्वर को JS API क्लाइंट कहते हैं।

चिंताओं को अलग करने से काफी फायदा होता है। और आपके पसंद (और मेरा) बैकएंड एपीआई को लागू करने वाले विशेषज्ञों को बहुत पसंद है, फ्रेमवर्क / http अनुरोध कोड के बारे में चिंता किए बिना आसानी से सामान्य भाषा कोड की तरह उनका परीक्षण करें।

यह वास्तव में उतना मुश्किल नहीं है जितना यह सामने की तरफ लगता है। क्या API कॉल और परिणामी डेटा (ज्यादातर json) आपके क्लाइंट साइड टेम्पलेट या MVC के लिए उपलब्ध है।

कम सर्वर साइड प्रोसेसिंग। इसका मतलब है कि आप कमोडिटी हार्डवेयर / कम महंगे सर्वर के लिए जा सकते हैं।

स्वतंत्र रूप से परतों का परीक्षण करना आसान है, एपीआई डॉक्स उत्पन्न करना आसान है।

इसके कुछ डाउनसाइड हैं।

कई डेवलपर्स इसे इंजीनियर और समझने में कठिन पाते हैं। तो संभावना है कि वास्तुकला की आलोचना हो सकती है।

i18n / l10n कठोर है। चूंकि एचटीएमएल अनिवार्य रूप से निर्मित होता है इसलिए निर्माण का समय स्थिर होता है, प्रति समर्थित भाषा में कई बिल्ड की आवश्यकता होती है (जो जरूरी नहीं कि बुरी चीज हो)। लेकिन इसके साथ ही आपके पास l10n / i18n के आसपास कोने के मामले हो सकते हैं और सावधान रहने की जरूरत है।

विकल्प 3

इस मामले में बैकएंड कोडिंग दूसरे विकल्प के समान होनी चाहिए। विकल्प 2 के अधिकांश बिंदु यहां भी लागू हैं।

वेब पेज सर्वर साइड टेम्प्लेट का उपयोग करके रनटाइम प्रदान किए जाते हैं। यह i18n / l10n को अधिक स्थापित / स्वीकृत तकनीकों के साथ बहुत आसान बनाता है। उपयोगकर्ता, भाषा, मुद्रा आदि जैसे पेज रेंडरिंग के लिए आवश्यक कुछ आवश्यक संदर्भ के लिए एक कम http कॉल हो सकती है, इसलिए सर्वर साइड प्रोसेसिंग को रेंडरिंग के साथ बढ़ाया जाता है लेकिन संभवतः एपीआई सर्वर को कम http कॉल द्वारा मुआवजा दिया जाता है।

अब जब पृष्ठ सर्वर पर प्रदान किए गए सर्वर हैं, तो दृश्यपटल अब प्रोग्रामिंग वातावरण के साथ अधिक बंधा हुआ है। यह कई अनुप्रयोगों के लिए एक विचार भी नहीं हो सकता है।

ट्विटर का मामला

जैसा कि मैं समझता हूं, ट्विटर सर्वर पर अपना प्रारंभिक पेज रेंडरिंग कर सकता है लेकिन पेज अपडेट के लिए इसमें अभी भी कुछ एपीआई कॉल और क्लाइंट साइड टेम्पलेट हैं जो डोम में हेरफेर करते हैं। तो ऐसे मामले में आपके पास बनाए रखने के लिए दोहरे टेम्पलेट हैं जो कुछ ओवरहेड और जटिलता को जोड़ता है। हर कोई ट्विटर के विपरीत इस विकल्प को नहीं खरीद सकता है।

हमारा प्रोजेक्ट स्टैक

मैं पायथन का उपयोग करने के लिए होता हूं। मैं REST के बजाय JsonRPC 2.0 का उपयोग करता हूं। मैं REST का सुझाव देता हूं, हालांकि मुझे विभिन्न कारणों से JsonRPC का विचार पसंद है। मैं पुस्तकालयों के नीचे उपयोग करता हूं। विकल्प 2/3 पर विचार करने वाला कोई व्यक्ति इसे उपयोगी पा सकता है।

एपीआई सर्वर: पायथन एक तेज वेब माइक्रो फ्रेमवर्क - फ्लास्क
सीमावर्ती सर्वर: Nginx
ग्राहक पक्ष MVC: नॉकआउट। जेएस
अन्य प्रासंगिक उपकरण / कार्य:
- jQuery
- लेखांकन। मुद्रा मुद्रा के लिए
- वेबसम : क्रॉस ब्राउज़र पॉलीफिल
- निर्देशक : क्लाइंट साइड रूटिंग
- sphc : HTML जनरेशन

मेरा निष्कर्ष और सिफारिश

विकल्प 3 !.

सभी ने कहा, मैंने विकल्प 2 का सफलतापूर्वक उपयोग किया है, लेकिन अब कुछ सरलता के लिए विकल्प 3 की ओर झुकाव है। बिल्ड स्क्रिप्ट के साथ स्टेटिक HTML पेज बनाना और उन्हें अल्ट्रा फास्ट सर्वर में से एक के साथ परोसना जो स्टेटिक पेज को परोसने में बहुत ही लुभावना है (विकल्प 2)।

— शेखर
स्रोत

मुझे विकल्प 2 भी पसंद है, लेकिन विकल्प 3 के बहुत सारे फायदे हैं जिनसे हम छुटकारा नहीं पा सकते हैं। मैं दोनों ऑप्ट 2 + ऑप्ट 3 के संयोजन से कुछ हाइड्रिड-सॉल्यूशन खोजने की कोशिश कर रहा हूं, लेकिन यह ट्विटर जैसे सिरदर्द को जन्म देगा।

— ब्लू स्मिथ

मुझे विकल्प 3 पसंद है, और यदि वर्तमान परियोजना के लिए उपयोग करने का लक्ष्य है। किसी भी उदाहरण या git रेपो आप मदद के लिए इंगित कर सकते हैं?

— AmaChefe

@AmaChefe मैं चाहता हूँ। वर्तमान परियोजना के लिए जहां एसईओ महत्वपूर्ण है हम विकल्प 3 का उपयोग करते हैं। लेकिन कोड खुला स्रोत नहीं है। हम फ्लास्क + jinja2 और नॉकआउट / प्रतिक्रिया.js का उपयोग करते हैं।

— शेखर

28

जब हमने gaug.es का निर्माण किया तो हमने # 2 का विकल्प चुना। मैंने एपीआई (रूबी, सिनट्रा, आदि) पर काम किया और मेरे बिजनेस पार्टनर स्टीव स्मिथ ने फ्रंट-एंड (जावास्क्रिप्ट क्लाइंट) पर काम किया।

पेशेवरों:

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

विपक्ष:

पिछेड़ी संगतता। यह आपके प्रत्यक्ष प्रश्न की तुलना में एक एपीआई से अधिक संबंधित है, लेकिन एक बार जब आपका एपीआई बाहर हो जाता है, तो आप इसे तोड़ नहीं सकते हैं या आप अपने सभी ग्राहकों को दो तोड़ सकते हैं। इसका मतलब यह नहीं है कि आपको धीमी गति से आगे बढ़ना है, लेकिन इसका मतलब यह है कि आपको अक्सर दो चीजों को एक साथ काम करना होगा। API या नए फ़ील्ड्स को जोड़ना ठीक है, लेकिन वर्जनिंग के बिना बदलना / हटाना नहीं होना चाहिए।

मैं अब और बुरा नहीं सोच सकता।

निष्कर्ष: एपीआई + जेएस क्लाइंट एक एपीआई जारी करने पर योजना बनाने का तरीका है।

पीएस मैं इसे जारी करने से पहले आपके एपीआई को पूरी तरह से प्रलेखित करने की भी सिफारिश करूंगा। Gaug.es एपीआई को दस्तावेज करने की प्रक्रिया ने वास्तव में हमें छोटा सा भूत बनाने में मदद की

http://get.gaug.es/documentation/api/

— जॉन नूनमेकर
स्रोत

13

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

— सेबेस्टियन रेम्बा

@SebastianWramba यह देर हो चुकी है, लेकिन जब से आपकी टिप्पणी को 12 upvotes मिला है ... मैं OAuth2 के पासवर्ड प्राधिकरण की तरह कुछ देखूंगा । यदि आप एपीआई को कॉल करने वाले ऐप के निर्माता हैं, तो यह वह दृष्टिकोण है जो आप शायद चाहते हैं, क्योंकि यह सीधे एपीआई कुंजी का उपयोग नहीं करता है। यदि यह एक तृतीय पक्ष ऐप है, तो आपके पास अपनी API कुंजी प्राप्त करने के लिए उपयोगकर्ता आपकी वेबसाइट पर लॉगिन करता है, और फिर उपयोगकर्ता अपने ऐप, वेबसाइट आदि के माध्यम से एपीआई तक पहुंचने के लिए उस कुंजी (और किसी अन्य आवश्यक क्रेडेंशियल्स) का उपयोग करता है

— GreeKatrina

10

मैं # 2 और # 3 के रूट पर जाना पसंद करता हूं। मुख्य रूप से क्योंकि # 1 चिंताओं के अलगाव का उल्लंघन करता है और सभी प्रकार के सामानों को आपस में जोड़ता है। आखिरकार आपको एक एपीआई एंड पॉइंट की आवश्यकता होगी जिसमें एक मिलान वाला HTML पेज / आदि न हो और आप एक कोड कोड में HTML और JSON अंतबिंदुओं के साथ एक अपंग हो। यह एक भयावह गंदगी में बदल जाता है, भले ही इसके एमवीपी, आपको अंततः इसे फिर से लिखना होगा, क्योंकि इसका एकमात्र गड़बड़ यह है कि इसके लायक भी नहीं है।

# 2 या # 3 के साथ जाने से आपको पूरी तरह से एक एपीआई प्राप्त होता है जो समान रूप से (अधिकांश भाग के लिए) कार्य करता है। यह महान लचीलापन प्रदान करता है। मैं बैकबोन / एम्बर / जो कुछ भी / etcjs पर अभी तक 100% नहीं बेच रहा हूँ। मुझे लगता है कि यह बहुत अच्छा है, लेकिन जैसा कि हम ट्विटर के साथ देख रहे हैं यह इष्टतम नहीं है। लेकिन ... ट्विटर भी एक कंपनी का बहुत बड़ा जानवर है और इसके करोड़ों उपयोगकर्ता हैं। इसलिए किसी भी सुधार का विभिन्न व्यावसायिक इकाइयों के विभिन्न क्षेत्रों में नीचे की रेखा पर भारी प्रभाव पड़ सकता है। मुझे लगता है कि अकेले गति की तुलना में निर्णय के लिए अधिक है और वे हमें उस पर नहीं दे रहे हैं। लेकिन यह महज मेरी राय है। हालांकि, मैं बैकबोन और इसके प्रतियोगियों को छूट नहीं देता हूं। ये एप्लिकेशन उपयोग करने के लिए बहुत बढ़िया हैं और बहुत साफ हैं और बहुत संवेदनशील हैं (अधिकांश भाग के लिए)।

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

मुझे लगता है कि यह उन लोगों में से एक है जो "समस्याओं के प्रकार" पर निर्भर हैं और उत्तर "यह निर्भर करता है" कि आप क्या कर रहे हैं, आप किसकी सेवा कर रहे हैं और आप उन्हें किस तरह का अनुभव प्राप्त करना चाहते हैं। यह देखते हुए कि मुझे लगता है कि आप 2 या 3 या उनमें से एक हाइब्रिड के बीच फैसला कर सकते हैं।

— डॉन फेलकर
स्रोत

+1 से 2 और 3 के हाइब्रिड

— उज्जवल ओझा

7

मैं वर्तमान में विकल्प 1 से विकल्प 3 तक एक विशाल सीएमएस को परिवर्तित करने पर काम कर रहा हूं, और यह अच्छी तरह से चल रहा है। हमने मार्कअप सर्वर-साइड रेंडर करने के लिए चुना क्योंकि एसईओ हमारे लिए एक बड़ी बात है, और हम चाहते हैं कि साइटें मोबाइल फोन पर अच्छा प्रदर्शन करें।

मैं क्लाइंट के बैक-एंड और मुट्ठी भर मॉड्यूल के लिए नोड.जेएस का उपयोग कर रहा हूं ताकि मुझे मदद मिल सके। मैं प्रक्रिया में कुछ जल्दी हूं, लेकिन नींव सेट है और यह डेटा पर जाने की बात है जो यह सुनिश्चित करता है कि यह सब सही हो। यहाँ मैं उपयोग कर रहा हूँ:

ऐप की नींव के लिए व्यक्त करें।
(https://github.com/visionmedia/express)
डेटा लाने का अनुरोध।
(https://github.com/mikeal/request)
अंडरस्कोर टेम्प्लेट जो कि सर्वर साइड प्रदान करते हैं। मैं क्लाइंट पर इनका पुन: उपयोग करता हूं।
(https://github.com/documentcloud/underscore)
एक्सप्रेस के साथ काम करने के लिए UTML अंडरस्कोर के टेम्प्लेट को लपेटता है।
(https://github.com/mikefrey/utml)
अपफ्रंट टेम्प्लेट एकत्र करता है और आपको चुना जाता है जो क्लाइंट को भेजा जाता है।
(https://github.com/mrDarcyMurphy/upfront)
एक्सप्रेस एक्सपोज़ भ्रूण के डेटा, कुछ मॉड्यूल, और टेम्प्लेट को फ्रंट-एंड से गुजरता है।
(https://github.com/visionmedia/express-expose)
बैकबोन डेटा को निगलने के बाद फ्रंट-एंड पर मॉडल और दृश्य बनाता है जो कि पास हो गया।
(https://github.com/documentcloud/backbone)

यह स्टैक का मूल है। कुछ अन्य मॉड्यूल जिन्हें मैंने उपयोगी पाया है:

fleck (https // github.com / trek / fleck)
पल (https // github.com / timrwood / पल)
स्टाइलस (https // github.com / LearnBoost / स्टाइलस)
smoosh (https // github.com / fat / smoosh)
... हालांकि मैं ग्रंट (https // github.com / काउबॉय / ग्रंट) में देख रहा हूं
कंसोल ट्रेस (//github.com/LearnBoost/console-trace)।

नहीं, मैं कॉफ़ीस्क्रिप्ट का उपयोग नहीं कर रहा हूं।

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

(अजीब लिंक के लिए खेद है, मैं ढेर के लिए एक n00b की बहुत अधिक हूँ, मुझे कई पोस्ट करने के लिए ढेर अतिप्रवाह के लिए)

— डार्सी मर्फी
स्रोत

1

तो आप मार्कअप सर्वर-साइड दे रहे हैं लेकिन आप अभी भी क्लाइंट को टेम्प्लेट दे रहे हैं और बैकबोन का उपयोग कर रहे हैं?

— शैनन

7

हम # 3 के निम्न प्रकार का उपयोग करते हैं: JSON-केवल REST API सर्वर बनाएं। एक HTML वेबसाइट सर्वर बनाओ। HTML वेब सर्वर आपके वैरिएंट की तरह नहीं है, REST API सर्वर का क्लाइंट है। इसके बजाय, दोनों सहकर्मी हैं। सतह से नीचे नहीं, एक आंतरिक एपीआई है जो कार्यक्षमता प्रदान करता है जिसकी दो सर्वरों को आवश्यकता होती है।

हम किसी भी मिसाल से वाकिफ नहीं हैं, इसलिए यह प्रायोगिक है। अब तक (बीटा में प्रवेश करने के बारे में), इसने बहुत अच्छा काम किया है।

— थॉमस बेकर
स्रोत

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

— मार्टिनॉड

2

@MartinodF हम Google ऐप इंजन पर होस्ट करते हैं, जो जावा या पायथन तक सीमित है। पाइथन का उपयोग करना चाहते थे, लेकिन जावा में मजबूर थे क्योंकि हम क्रंच संख्या (जीएई पर सी / सी ++ के साथ पाइ का विस्तार नहीं कर सकते)। हम धारियों (पट्टियों, चुना नहीं Struts, नहीं प्रस्तुति ढांचे के लिए स्प्रिंग)। इससे बहुत खुश हूं। पूरी बात जीएई पर एक जावा ऐप है। कोर कार्यक्षमता जावा संकुल के एक समूह में लागू होती है और एक आंतरिक एपीआई में उजागर होती है। एक सर्वलेट है जो JSON REST सेवा प्रदान करता है, और दूसरा जिसे स्ट्राइप्स वेब ऐप के रूप में कॉन्फ़िगर किया गया है। चूंकि यह सभी एक जीएई जावा ऐप है, इसलिए संचार तुच्छ है।

— थॉमस बेकर

अंतर्दृष्टि के लिए धन्यवाद, यह बहुत उपयोगी है!

— मार्टिनॉड

7

मैं आमतौर पर 2 विकल्प के लिए जा रहा हूं, रेल का उपयोग एपीआई बनाने के लिए, और जेएस सामान के लिए बैकबोन। आप ActiveAdmin का उपयोग करके मुफ्त में एक व्यवस्थापक पैनल भी प्राप्त कर सकते हैं । मैंने इस तरह के बैकएंड के साथ दसियों मोबाइल ऐप्स शिप किए हैं। हालाँकि यह बहुत हद तक निर्भर करता है कि आपका ऐप इंटरएक्टिव है या नहीं।

मैंने इस दृष्टिकोण पर पिछले RubyDay.it में एक प्रस्तुति दी : http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

तीसरे विकल्प के लिए, 2 की जवाबदेही पाने के लिए, आप पजाक्स को आज़माना चाह सकते हैं जैसा कि गितुब करता है।

— मत्तेओ कोलिना
स्रोत

6

मैं 3 महीने के प्रोजेक्ट में लगभग 2 महीने का हूं जो आपके द्वारा उल्लिखित दूसरा दृष्टिकोण लेता है। हम फ्रंट पर backbone.js के साथ एक RESTful API सर्वर साइड का उपयोग करते हैं। Handlebars.js टेम्पलेट्स का प्रबंधन करता है और jQuery AJAX और DOM हेरफेर को संभालता है। पुराने ब्राउज़रों और खोज मकड़ियों के लिए हम सर्वर साइड रेंडरिंग पर वापस आ गए हैं, लेकिन हम उसी HTML टेम्प्लेट का उपयोग कर रहे हैं, जो हैंडलबार फ्रंटेंड के रूप में मोज़िला राइनो का उपयोग कर रहा है।

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

अब तक हम सिर्फ एक एपीआई के साथ काम कर रहे हैं, लेकिन परियोजना के अगले चरण में हम दूसरे एपीआई के साथ काम करेंगे। पहला बड़ी मात्रा में डेटा के लिए है, और दूसरा एक एपीआई के माध्यम से सीएमएस की तरह काम करता है।

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

मुझे डर है कि मैं रूबी आदमी नहीं हूं इसलिए मैं अन्य दृष्टिकोणों पर टिप्पणी नहीं कर सकता। कभी-कभी रिस्क लेना ठीक रहता है। दूसरी बार इसे सुरक्षित खेलने के लिए बेहतर है। आप अपने आप को प्रोजेक्ट के प्रकार के आधार पर उल्लू करेंगे।

यहां आपकी पसंद के साथ शुभकामनाएं। यह देखने के लिए उत्सुक हैं कि अन्य लोग क्या साझा करते हैं।

— इराफ्लिथ केली
स्रोत

1

तो आप पता लगाएं कि क्या खोज बॉट से अनुरोध आ रहा है, और यदि यह नहीं है तो पूर्व-प्रदत्त HTML की सेवा करें, और JS + टेम्पलेट?

— शैनन

4

मुझे # 3 पसंद है जब मेरी वेबसाइट मेरे डेटा का 100% CRUD कार्यान्वयन नहीं होने जा रही है। जो होना अभी बाकी है।

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

मैं इसके बारे में चिंता नहीं करता हूं और अगर मुझे इसकी आवश्यकता है तो बस उपयोगकर्ता पक्ष से एक दृढ़ता परत क्वेरी करें। मैं पूरी तरह से अलग होने के साथ संबंध नहीं रखता हूं क्योंकि वे आमतौर पर विभिन्न उद्देश्यों की पूर्ति करते हैं।

यहां कई रैक ऐप्स का उपयोग करने का एक बहुत ही सरल उदाहरण है। मैंने आपको एपीआई ऐप को हिट करने के लिए वहां एक त्वरित jquery उदाहरण जोड़ा। आप यह देख सकते हैं कि यह अलग-अलग उद्देश्यों के साथ पापात्रा और बढ़ते कई रैक ऐप के साथ कितना सरल हो सकता है।

https://github.com/dusty/multi-rack-app-app

— मटमैला
स्रोत

1

यहाँ कुछ शानदार उत्तर पहले से ही हैं - मैं निश्चित रूप से # 2 या # 3 की सिफारिश करूंगा - अलगाव वैचारिक रूप से अच्छा है, लेकिन व्यवहार में भी है।

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

# 2 # 3 के बीच यह वास्तव में आपके लक्ष्यों पर निर्भर करता है - मैं सहमत हूँ कि # 2 शायद वेबैप्स का भविष्य है - लेकिन शायद आप कुछ और सीधा चाहते हैं अगर वह चैनल केवल बहुतों में से एक होने जा रहा है!

— स्टीव
स्रोत

1

Atyourservice.com.cy के लिए हम विशेष रूप से se भाग को कवर करने के लिए पृष्ठों के लिए सर्वर साइड प्रदान किए गए टेम्प्लेट का उपयोग कर रहे हैं। और पेज लोड होने के बाद बातचीत के लिए एपीआई का उपयोग करना। चूँकि हमारा फ्रेमवर्क MVC है, इसलिए सभी आउटपुट फ़ंक्शंस को डुप्लिकेट करके json आउटपुट और html आउटपुट में बनाया जाता है। टेम्पलेट साफ हैं और केवल एक वस्तु प्राप्त करते हैं। इसे सेकंड में js टेम्प्लेट में बदला जा सकता है। हम हमेशा सर्वरसाइड टेंपरेचर बनाए रखते हैं और रिक्वेस्ट पर सिर्फ js को ही रिवर्ट करते हैं।

— xatzistnr
स्रोत

1

आइसोमॉर्फिक प्रतिपादन और प्रगतिशील वृद्धि। जो मुझे लगता है कि आप विकल्प तीन में नेतृत्व कर रहे थे।

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

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

हां, इस ऐप की कार्यक्षमता के लिए एक स्टैंडअलोन जोंस एपी जरूर लिखें। लेकिन इतनी दूर मत जाओ कि आप स्थिर HTML दस्तावेजों के रूप में ठीक काम करने वाली चीजों के लिए एक json api लिखें।

— sirtimbly
स्रोत

1

REST सर्वर + जावास्क्रिप्ट-भारी क्लाइंट वह सिद्धांत था जिसका मैंने अपने हालिया काम में पालन किया है।

बाकी सर्वर में लागू किया गया था Node.js + एक्सप्रेस + MongoDB (बहुत अच्छा लेखन प्रदर्शन) + नेवला ODM (डेटा मॉडलिंग के लिए महान, सत्यापन शामिल है) + CoffeeScript (मैं ES2015 अब जाना चाहते हैं बजाय) जो मेरे लिए अच्छी तरह से काम किया। अन्य संभावित सर्वर-साइड तकनीकों की तुलना में Node.js अपेक्षाकृत युवा हो सकते हैं, लेकिन इससे मुझे एकीकृत भुगतान के साथ ठोस एपीआई लिखना संभव हो गया।

मैंने Ember.js का उपयोग जावास्क्रिप्ट ढांचे के रूप में किया है और अधिकांश अनुप्रयोग तर्क ब्राउज़र में निष्पादित किए गए हैं। मैंने CSS प्री-प्रोसेसिंग के लिए SASS (SCSS विशेष रूप से) का उपयोग किया है ।

एम्बर मजबूत समुदाय द्वारा समर्थित परिपक्व ढांचा है। यह बहुत शक्तिशाली ढांचा है जिसमें हाल ही में प्रदर्शन पर ध्यान केंद्रित किया गया है, जैसे ब्रांड न्यू ग्लमर रेंडरिंग इंजन (रिएक्ट से प्रेरित)।

एम्बर कोर टीम फास्टबूट विकसित करने की प्रक्रिया में है , जो आपको सर्वर-साइड (विशेष रूप से नोड्स) पर अपने जावास्क्रिप्ट एम्बर तर्क को निष्पादित करने के लिए और उपयोगकर्ता को आपके एप्लिकेशन के प्री-रेंडर किए गए HTML (जो सामान्य रूप से ब्राउज़र में चलाया जाएगा) को भेजने की प्रक्रिया में है। यह एसईओ और उपयोगकर्ता अनुभव के लिए बहुत अच्छा है क्योंकि वह पृष्ठ प्रदर्शित होने के लिए इतनी देर तक इंतजार नहीं करता है।

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

एक्सप्रेस के माध्यम से सब कुछ परोसने के लिए नहीं, मैंने nginx का उपयोग छवियों और जावास्क्रिप्ट-भारी क्लाइंट की सेवा के लिए किया है। मेरे मामले में nginx प्रॉक्सी का उपयोग करना सहायक था:

upstream app_appName.com {
  # replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
  server 0.0.0.0:1000;
  keepalive 8;
}

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  client_max_body_size 32M;

  access_log  /var/log/nginx/appName.access.log;
  error_log  /var/log/nginx/appName.error.log;

  server_name appName.com appName;

  location / {
     # frontend assets path
     root /var/www/html;
     index index.html;

     # to handle Ember routing
     try_files $uri $uri/ /index.html?/$request_uri;
  }

  location /i/ {
    alias /var/i/img/;
  }

  location /api/v1/ {
    proxy_pass  http://app_appName.com;

    proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

प्रो: मुझे एपीआई और क्लाइंट के अलगाव से प्यार है। स्मार्ट लोग कहते हैं कि यह रास्ता है। सिद्धांत रूप में महान। अत्याधुनिक और रोमांचक लगता है।

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

Con: बहुत अधिक मिसाल नहीं। इसके कई उदाहरणों ने अच्छा नहीं किया। सार्वजनिक उदाहरण (twitter.com) सुस्त महसूस करते हैं और यहां तक कि इस दृष्टिकोण से दूर जा रहे हैं।

चीजें अब अलग दिखती हैं। REST API + करने वाले बहुत से ग्राहक इसका सेवन करने के बहुत से उदाहरण हैं।

— डैनियल Kmak
स्रोत

1

मैंने Infiniforms के लिए विकल्प # 2 की वास्तुकला के लिए जाने का फैसला किया , क्योंकि इसने यूआई को व्यावसायिक तर्क से अलग करने का एक शानदार तरीका प्रदान किया।

इसका एक फायदा यह है कि एपीआई सर्वर स्वतंत्र रूप से वेब सर्वर को स्केल कर सकता है। यदि आपके पास कई क्लाइंट्स हैं, तो वेबसाइटों को वेब सर्वरों की तरह ही बड़े पैमाने पर करने की आवश्यकता नहीं होगी, क्योंकि कुछ ग्राहक फोन / टैबलेट या डेस्कटॉप आधारित होंगे।

यह दृष्टिकोण आपको अपने उपयोगकर्ताओं के लिए अपना एपीआई खोलने के लिए एक अच्छा आधार भी देता है, खासकर यदि आप अपनी वेबसाइट पर सभी कार्यक्षमता प्रदान करने के लिए अपने स्वयं के एपीआई का उपयोग करते हैं।

— कार्ल गजर्टसन
स्रोत

1

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

मेरे विचार इस प्रकार हैं: - कुछ ऐसे मॉड्यूल बनाएं जिनमें एपीआई कंट्रोलर और एचटीएमएल कंट्रोलर के बीच आम तर्क हो, जो बिना जीसस को लौटाए या HTML रेंडर किए हुए हों, और इस मॉड्यूल को HTML कंट्रोलर और एपीआई कंट्रोलर दोनों में शामिल करें, फिर आप जो चाहें करें, उदाहरण के लिए :

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end


class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end



module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end

0

मैं एक हाइब्रिड एप्रोच के लिए गया हूँ जहाँ हम एक आधार, ActiveRecord / Postgress इत्यादि के रूप में यूजर सिनात्रा को पेज रूट्स (स्लिम टेम्प्लेट) परोसने के लिए एक REST API का खुलासा करते हैं जिसे वेब-ऐप इस्तेमाल कर सकता है। शुरुआती विकास के सामान में, जैसे कि चुनिंदा विकल्पों को स्लिम टेम्प्लेट में प्रस्तुत करने वाले हेल्पर्स के माध्यम से किया जाता है, लेकिन जैसा कि हम उत्पादन के लिए दृष्टिकोण करते हैं, यह एक AJAX कॉल के लिए एक स्वैप एपीआई के लिए स्वैप हो जाता है क्योंकि हम पेज-लोड गति और इसके बाद के बारे में अधिक देखभाल करना शुरू करते हैं।

सामान है कि स्लिम में प्रस्तुत करना आसान है कि इस तरह से संभाला जाता है, और सामान (आबादी रूपों, jQuery से फार्म POST डेटा प्राप्त कर रहा है। अमान्य है submitHandlerआदि, सब स्पष्ट रूप से AJAX है)

परीक्षण एक मुद्दा है। अभी मैं स्टम्प्ड हूं JSON डेटा को एक रैक :: टेस्ट POST परीक्षण में पास करने की कोशिश कर ।

— डेव सग
स्रोत

0

मैं व्यक्तिगत रूप से समाधान के रूप में विकल्प (3) पसंद करता हूं। यह सिर्फ उन सभी साइटों के बारे में है जिनका एक पूर्व (घरेलू नाम) नियोक्ता मेरा है। इसका मतलब है कि आप कुछ फ्रंट-एंड देवता प्राप्त कर सकते हैं जो जावास्क्रिप्ट, ब्राउज़र क्विरक्स और व्हाट्सएप के बारे में सभी जानते हैं। उन्हें केवल "कर्ल एक्सयज जानने की जरूरत है और आपको कुछ जुबान मिल जाएगी" और वे चले जाते हैं।

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

विकल्प 3 आपको एक अच्छा, ठोस तीन स्तरीय वास्तुकला देता है। इसका मतलब है कि जो सामान आप सामने के छोर से बाहर थूकते हैं, वह एसईओ के अनुकूल है, जिसे पुराने या नए ब्राउज़रों (और जेएस के साथ बंद) के साथ काम करने के लिए बनाया जा सकता है, और यदि आप चाहें तो जावास्क्रिप्ट क्लाइंट साइड टेम्प्लेटिंग अभी भी हो सकता है (इसलिए आप कर सकते हैं स्थिर HTML वाले पुराने ब्राउज़र / googlebot को हैंडल करने जैसी चीज़ें करें, लेकिन नवीनतम Chrome ब्राउज़र या जो भी हो, का उपयोग करके लोगों को JS निर्मित गतिशील अनुभव भेजें।

सभी मामलों में मैंने विकल्प 3 को देखा है, यह कुछ PHP का एक कस्टम कार्यान्वयन है जो विशेष रूप से परियोजनाओं के बीच हस्तांतरणीय नहीं है, अकेले भूमि को खोलने के लिए बाहर जाने दें। मुझे लगता है कि हाल ही में PHP को रूबी / रेल से बदल दिया गया है, लेकिन उसी तरह की बात अभी भी सच है।

FWIW, $ current_employer कुछ महत्वपूर्ण स्थानों में विकल्प 3 के साथ कर सकता है। मैं एक अच्छे रूबी ढांचे की तलाश कर रहा हूं जिसमें कुछ बनाने के लिए। मुझे यकीन है कि मैं रत्नों के भार को एक साथ जोड़ सकता हूं, लेकिन मैं एक एकल उत्पाद को पसंद करूंगा जो मोटे तौर पर एक टेम्प्लेटिंग, 'कर्लिंग', वैकल्पिक-प्रमाणीकरण, वैकल्पिक मेमकेच / नोस्कल कनेक्टेड कैशिंग समाधान प्रदान करता है। वहाँ मैं कुछ भी सुसंगत खोजने में विफल रहा हूँ :-(

— राल्फ बोल्टन
स्रोत

0

रेल में JSON एपीआई का निर्माण प्रथम श्रेणी है, JSONAPI :: संसाधन मणि एक http://jsonapi.org सट्टेबाजी एपीआई के लिए भारी उठाने करता है।

— pixelhandler
स्रोत

अलग जंग JSON एपीआई सर्वर और ग्राहक? [बन्द है]

नाखूनों में चोट

रेस्ट सर्वर्स + जावासिपेट-हेवी क्लिंट

अन्य सर्वर + SERVER-SIDE HTML ग्राहक

विकल्प 1

विकल्प 2

विकल्प 3

ट्विटर का मामला

हमारा प्रोजेक्ट स्टैक

मेरा निष्कर्ष और सिफारिश