बाकी एपीआई उद्देश्य?


17

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

मैंने उनके आधिकारिक डॉक्स, बहुत सारे अन्य लेख पढ़े हैं और ट्यूटोरियल वीडियो देखे हैं, लेकिन इम को अभी भी कुछ बिंदु नहीं मिल रहे हैं .. यह निश्चित रूप से वर्डप्रेस का भविष्य है, यह मोबाइल ऐप डेवलपमेंट और डेटा के बीच / साझा करने के लिए बहुत आसान है विभिन्न साइटें: लेकिन यह केवल मेरी साइट के लिए क्या करती है?


इस पर विचार करो:

Im वर्तमान में टिप्पणियों पर काम कर रहा है। मैं टिप्पणी अनुभाग को केवल तब लोड करना चाहता हूं जब उपयोगकर्ता टिप्पणी अनुभाग (-200px ऑफसेट के साथ स्क्रॉल करता है , ताकि कोई देरी न हो)

  • जब उपयोगकर्ता उस बिंदु तक स्क्रॉल करता है तो मैं ajax कॉल को ट्रिगर करने जा रहा हूं
  • Ajax कॉल इसके साथ कुछ डेटा भेजता है, जैसे post_id आदि
  • WP_Comment_Query()सर्वर में चलाएं
  • JSONटिप्पणी संबंध, नाम, सामग्री आदि के साथ ग्राहक को डेटा वापस भेजें
  • उपयोग जावास्क्रिप्ट document.createElement(), innerHTML आदि बना सकते हैं और उत्पादन टिप्पणी करने के लिए

अब .. मैं इसके बजाय REST API का उपयोग क्यों करूंगा? मेरे लिए क्या उपयोग है? बस भविष्य के लिए?

मुझे अभी भी जावास्क्रिप्ट का उपयोग करने की आवश्यकता है जो मुझे प्राप्त होने वाले सभी डेटा को आउटपुट करने के लिए है .. मुझे कोई भी अच्छा लेख क्यों नहीं मिला या इसके लिए मुझे REST API का उपयोग क्यों करना चाहिए (साइट और मोबाइल ऐप डेवलपमेंट के बीच डेटा ट्रांसफर को छोड़कर) ।।


आपके द्वारा बताए गए तरीके के पक्ष में REST API का उपयोग करने से आपको एक संरचित और एकीकृत तरीके का लाभ मिलेगा । आपको सामग्री संग्राहकों (टिप्पणी क्वेरी) या प्रतिक्रिया प्रारूप (json) से निपटने की आवश्यकता नहीं है। कैशिंग के साथ कुछ सुधार भी हो सकते हैं। मैं सामान्य तौर पर जो नकारात्मक पहलू देख रहा हूं, वह यह है कि गतिरोध पूरी तरह से ब्राउज़र में चला जाता है - जो मेरे »बैकएंड-डेवलपर« राय - के मुद्दों को उठाता है।
डेविड

आप ग्राहक को JSON डेटा वापस भेजने की योजना कैसे बनाते हैं? आप सर्वर साइड कोड का निर्माण कैसे कर रहे हैं?
czerspalace


@ डेविड मूल रूप से REST API सभी क्वेरीज़ को खुद करता है और मुझे इसे पैरामीटर के रूप में क्वेरी स्ट्रिंग को फीड करने की आवश्यकता है? टेम्प्लेटिंग के बारे में .. मैं देख रहा हूं कि आप क्या कह रहे हैं, सौभाग्य से हर साल हार्डवेयर अधिक शक्तिशाली होता है। दुर्भाग्य से हमेशा ऐसे लोग होंगे जो उस मामले (पुराने IE उपयोगकर्ताओं, इम को आपकी ओर देखते हुए) में इंकार करने से इनकार करते हैं ।
N00b

@czerspalace 1. WP_Comment_Query() 2.while लूप में पैरामीटर के साथ प्रत्येक के साथ टिप्पणियों की सरणी का निर्माण 3. json_encode() 4. echo वापस डेटा एन्कोड किया गया। wp_ajaxऔर / या wp_ajax_noprivफ़ंक्शन में यह सब ।
N00b

जवाबों:


8

अपनी वर्तमान स्थिति में, यह एक बुरी तरह से इंजीनियर सुविधा है जो एक सक्षम डेवलपर के लिए कोई वास्तविक लाभ नहीं है।

मूल विचार, जैसा कि इस उत्तर के लिखे जाने के समय है, वर्डप्रेस कोर कार्यक्षमता को JSON REST API के रूप में उजागर करना है। यह यूआई से वर्डप्रेस "व्यापार" तर्क को डिकूप करने में सक्षम होगा और वर्डप्रेस के बारे में जानकारी का प्रबंधन और निकालने के लिए विभिन्न पूर्ण या आंशिक UI बनाने में सक्षम करेगा। यह अपने आप में एक क्रांति नहीं है, बल्कि एक विकास है। XML-RPC API का केवल एक प्रतिस्थापन जो कि थोड़े से ही सबमिशन एपीआई के आधार पर HTTP को सुव्यवस्थित करता है।

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

तो इस उत्तर के लिए नकारात्मक प्रस्तावना क्यों? क्योंकि सॉफ्टवेयर डेवलपर के रूप में मेरा अनुभव यह है कि जेनेरिक एपीआई को डिजाइन करना बहुत कम संभव है जो जवाब देने के लिए ठोस उपयोग के मामलों के बिना वास्तव में उपयोगी हो। यहां एक ठोस उपयोग का मामला XML-RPC API को स्वचालित वर्डप्रेस प्रबंधन के लिए प्रतिस्थापित कर सकता है, लेकिन संबंधित किसी भी फ्रंट एंड को साइट विशिष्ट होना चाहिए और चूंकि क्लाइंट से सर्वर पर भेजे गए हर अनुरोध के लिए बहुत बड़ा प्रदर्शन जुर्माना है, जो आप नहीं कर सकते अलग-अलग एपीआई का समुचित उपयोग आप जिस तरह से करना चाहते हैं, उस तरह से प्राप्त करने के लिए, जिसमें उपयोगकर्ता खुश रहेंगे। इसका मतलब है कि सामने के अंत के लिए, गैर तुच्छ उपयोग के लिए, AJAX मार्ग और REST-API मार्ग का उपयोग करने के बीच विकास के प्रयासों में अभी भी बहुत कम अंतर होगा।


धन्यवाद, यह केवल चीजों को बदतर बनाता है! मैं ईमानदारी से सिर्फ अपना मन नहीं बना सकता कि कौन सी सड़क ले जाऊं .. मुझे पता है कि मुझे भविष्य में मोबाइल ऐप बनाने की आवश्यकता होगी। आपकी सलाह है कि वर्तमान स्थिति में REST API बकवास है ?
N00b

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

3

दो व्यापक लाभ हैं:

  1. आप (अंततः) व्यवस्थापक इंटरफ़ेस के बिना सभी व्यवस्थापक कार्य कर सकते हैं।
  2. आप प्रदर्शन के लिए सभी डेटा प्राप्त कर सकते हैं और फ्रंट एंड (और PHP लेखन) को पूरी तरह से समाप्त कर सकते हैं।

अपने उदाहरण के बारे में विशेष रूप से-

REST API के साथ चरण 3 और 4 बदलें, और Backbone.js के साथ चरण 1, 2 और 5 बदलें। बूम, गतिशील वेब अनुप्रयोग। या हो सकता है कि आप अपनी साइट के लिए आवश्यक जटिल रूटिंग कर रहे हों, बजाय इसके कि आप पायथन के साथ रहें।


Im इस तथ्य के बारे में बहुत चिढ़ है कि हर कोई ऑनलाइन कहता है कि डायनामिक वेब एप्लिकेशन अर्थ बहुत व्यक्तिपरक है (और यही कारण है कि वे वास्तव में यह नहीं बताते हैं कि) जिसका अर्थ है कि मैं 100% नहीं जानता कि यह डायनामिक वेबसाइट की तुलना में क्या है .. इसका आपका संस्करण क्या है? यह एक चीज की तरह है जिसे मुझे जानना आवश्यक है कि क्या REST API का उपयोग करना है या नहीं ..
N00b

2
आवेदन का अर्थ है स्थैतिक ब्लॉग पृष्ठों से परे कुछ और जो अन्य स्थिर ब्लॉग पेजों से जुड़ता है, एक अधिक सहज "अनुभव की तरह" ऐप। बैकबोन साइट पर उदाहरण के लिए नीचे स्क्रॉल करें ।
मिलो

3

खैर, कुछ चीजें वास्तव में।

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

  2. यह व्यापार तर्क और रेंडरर को अलग करता है। हां, आप एपीआई का उपयोग किसी अन्य PHP साइट के परिणामों को थूकने के लिए कर सकते हैं, या इसे जावास्क्रिप्ट के साथ संभाल सकते हैं, जैसे कि आपने उल्लेख किया है, लेकिन आप इसे देशी मोबाइल एप्लिकेशन, डेस्कटॉप एप्लिकेशन आदि के साथ भी उपभोग कर सकते हैं, न केवल आपके पास, बल्कि आपके पास भी हो सकता है एक ही एपीआई से बात करने वाले सभी में से एक, जो लगातार एक ही व्यापार तर्क करता है, जो बदले में एपीआई का उपभोग करने वाले विभिन्न ग्राहकों में स्थिरता और विश्वसनीयता बनाता है।

एपीआई अच्छे हैं क्योंकि वे तर्क और प्रदर्शन की चिंताओं को अलग करते हैं।


पहले बिंदु के बारे में .. नियमित जावास्क्रिप्ट की तुलना में बेहतर क्यों है अंतराल में अद्यतनों की जाँच करना और गतिशील रूप से अपडेट करना?
2100 पर N00b

2
खैर, "नियमित" अजाक्स कॉल सिर्फ एक एपीआई के लिए कॉल कर रहे हैं! वास्तव में कोई अंतर नहीं है। REST API का लक्ष्य कोर Wordpress की कार्यक्षमता के लिए इस तरह का एपीआई प्रदान करना है। इस तरह से आप AJAX, देशी ऐप, डेस्कटॉप ऐप आदि का उपयोग करके अधिक संचालन कर सकते हैं। इसका "REST" भाग नियमों / मानकों की एक प्रणाली है जो परिभाषित करता है कि एपीआई का निर्माण कैसे किया जाना चाहिए ताकि इसके साथ विकास करना आसान हो और बनाए रखें।
कोल्ट मैककॉर्मैक

2

वर्डप्रेस रीस्ट एपीआई नई हॉटनेस है। एकल पृष्ठ js संचालित अनुप्रयोगों के साथ, और वर्डप्रेस एक ऐप प्लेटफ़ॉर्म बनने की इच्छा रखते हैं जो बहुत मायने रखता है। योजना XML-RPC को REST API से बदलने की है (जो अकेले सुरक्षा कारणों से अच्छी बात है!)

https://make.wordpress.org/core/2015/09/21/wp-rest-api-merge-proposal/

  • न्यूयॉर्क टाइम्स नई साइट पर बनाया गया है, जाहिरा तौर पर
  • यह मोबाइल ऐप्स और अन्य बाहरी सेवाओं को wp सामग्री (जैसे wp-cli) तक पहुंचने की अनुमति देता है )
  • यह डेवलपर्स को सप्ताह के अपने पसंदीदा JSON खपत ढांचे के साथ एकल-पृष्ठ ऐप फ्रंट एंड बनाने की अनुमति देता है, और उनकी उंगलियों पर सभी शांत इंटरैक्शन होते हैं।
  • यह बैक-एंड और फ्रंट-एंड टीमों के बीच चिंताओं को अलग करने (जैसा कि ऊपर बताया गया है) और अधिक से अधिक स्वतंत्रता की अनुमति देता है।

यह वर्डप्रेस को आगे ले जाने के लिए टूल का एक और सेट है। और, हालाँकि यह हम कहाँ हैं के लिए पाने के लिए एक यात्रा है, मुझे लगता है कि यह समय का पता लगाने और इसे समझने के लिए लायक है।


1

पहले चीजें - आरईएसटी हल्का है

एक पंक्ति में - जब हम REST API का उपयोग करते हैं तो हम सभी डेटा रेंडरिंग क्लाइंट साइड (लूप्स, कंडीशंस और सर्वर साइड कॉल आदि) में करते हैं। बैंडविड्थ की बचत होती है और साथ ही साथ हमारा एप्लिकेशन किसी भी मोबाइल प्लेटफ़ॉर्म, 3rd पार्टी इंटीग्रेशन और मॉड्यूलर () के लिए तैयार हो जाता है। सीमा और सर्वर पक्ष के बीच चिंता का संबंध)।

क्या आप यह चाहते हैं?


0

2 महान बिंदुओं @Milo के अलावा, मैं विशेष रूप से गैर-वर्डप्रेस अनुप्रयोगों के लिए अपने डेटा को उजागर करने के लिए REST API का उपयोग करता हूं। हमारे पास एक Chrome एक्सटेंशन है जो हमारे वर्डप्रेस डेटाबेस से जानकारी खींचता है, और यह POST अनुरोधों के साथ REST API एंडपॉइंट्स को मारकर पूरा किया गया है।


0

संस्थागत अवसंरचना

REST API सुसंगत और मानव-पठनीय है। यह स्व-दस्तावेजीकरण है।

GET wp-json/wp/v2/postsयह स्पष्ट है कि यह क्या करता है। यहGET कुछ पोस्ट है।

आपके पास एक नाम स्थान है: wpएक संस्करण:v2 और एक वस्तु संग्रहposts

क्या आप अनुमान लगा सकते हैं: क्या GET wp-json/wp/v2/posts/5करता है? कैसा रहेगा :GET wp-json/wp/v2/posts/5/comments कैसे के बारे में:GET wp-json/shop/v2/orders/345/lines/11/price

एक डेवलपर को देखकर आसानी से अनुमान लगाया जा सकता है कि यह दस्तावेज को पढ़े बिना भी 11ऑर्डर पर लाइन की कीमत प्राप्त करने वाला है 345। देव आसानी से यह भी बता सकते हैं कि यह shopप्लगिन से आ रहा है क्योंकि यह नामांकित है।

कैसे के बारे POST /wp-json/v2/posts title=New Blog Post मेंPUT /wp-json/v2/posts title=New Title

यह भी स्पष्ट है। यह एक नई पोस्ट बनाता है। वैसे, यह नई पोस्ट की आईडी लौटाता है। यह AJAX या REST API के बारे में नहीं है। AJAX केवल एक तकनीक है जो REST API तक पहुँचता है। जबकि, इससे पहले, आपको सार अजाक्स फ़ंक्शन नामों की एक गुच्छा के साथ आना होगा: जैसे get_price_for_lineitem( $order, $line )। क्या यह केवल एक संख्या या JSON ऑब्जेक्ट को वापस करने जा रहा है? मुझे यकीन नहीं है, जहां प्रलेखन है। ओह ... अजाक्स कॉल था get_order_line_priceया get_lineitem_price

डेवलपर को इन निर्णयों को करने की आवश्यकता नहीं है, क्योंकि मौजूदा wp-jsonएपीआई आपके स्वयं के समापन बिंदु बनाते समय पालन करने के लिए एक अच्छा आधार मॉडल प्रदान करता है । निश्चित रूप से, एक प्लगइन या एपीआई डेवलपर इन नियमों को तोड़ सकता है, लेकिन सामान्य तौर पर एक मानक का पालन करना आसान होता है जो पहले से ही सेट किया गया है और अधिकांश डेवलपर्स पहले से सेट किए गए पैटर्न का पालन करेंगे (देखें कि अब pervasive jQuery पैटर्न कैसे हैं)।

व्याकुलता के बिना निर्माण

क्या मुझे इस बात की परवाह है कि कैसे POST /wp-json/mysite/v1/widgets title=Foobarकाम करता है? नहीं। मैं बस एक नया बनाना Widgetचाहता हूं और मुझे बदले में आईडी चाहिए। मैं पृष्ठ को ताज़ा किए बिना अपने सामने के छोर पर एक फ़ॉर्म से करना चाहता हूं। यदि मैं किसी URL से अनुरोध करता हूं, तो मुझे परवाह नहीं है कि यह PHP, C #, ASP.NET या कोई अन्य तकनीक है। मैं सिर्फ एक नया विजेट बनाना चाहता हूं।

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

यदि आपकी REST API सरल और सुसंगत है, तो संज्ञा का उपयोग करके Widgetsवस्तुओं के संग्रह के रूप में और संज्ञा / पहचानकर्ता Widget/2एक इकाई को इंगित करना पसंद करते हैं, यह वास्तव में उस API को एक विशाल भिन्न तकनीक में लिखना अधिक सरल है क्योंकि यह कमोबेश बुनियादी डेटाबेस प्लंबिंग है कोड।

मानक HTTP अनुरोध क्रियाओं का उपयोग करता है।

REST API वेब के काम करने के तरीके और VERBs (पढ़ें: कार्रवाई) के मूल का लाभ उठाता है, जो आप मानक डेटा एनएचडी कार्यों के लिए मानचित्र का उपयोग करते हैं।

CREATE : POST
READ   : GET
UPDATE : PUT/PATCH
DELETE : DELETE

अधिक HTTP क्रियाएं हैं, लेकिन वे मूल बातें हैं। इंटरनेट पर हर एक अनुरोध इन क्रियाओं का उपयोग करता है। REST API उस मॉडल के ठीक ऊपर बैठता है जिसे वेब अनुरोधों पर बनाया गया है। बीच में किसी भी संचार परत या अमूर्त मॉडल की आवश्यकता नहीं है। यह URL के लिए बस एक मानक http अनुरोध है और यह एक प्रतिक्रिया देता है। आप इससे ज्यादा सरल नहीं हो सकते।

अनिवार्य रूप से, यह एक डेवलपर को नट और बोल्ट के बारे में अधिक जानकारी देता है कि वेब वास्तव में कैसे काम करता है और जब आप यह समझने के करीब पहुंचते हैं कि अंतर्निहित प्रोटोकॉल कैसे काम करते हैं, तो आप एक अधिक कुशल बेहतर उत्पाद बनाते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.