WordPress REST API: الجيل القادم من ميزة CMS

يعمل أكثر من ربع الويب على WordPress. إنه إنجاز رائع للغاية ، بالنظر إلى أنه كان موجودًا منذ أكثر من عقد ، مما يجعله قديمًا إلى حد ما في سنوات التكنولوجيا.

ما هي الصلصة السرية لـ WordPress؟ سهل - إنها أبسط طريقة وأكثرها قابلية للتوسع لإدارة المحتوى الخاص بك. ومع ذلك ، لفترة من الوقت ، بدا أن WordPress قد تخلف عن الركب.

نظرًا لأن الويب أصبح أكثر اعتمادًا على JavaScript لإنشاء تجارب تفاعلية غامرة ، فقد أصبح من الواضح بشكل متزايد أن WordPress سيحتاج إلى تقديم طرق جديدة للمستخدمين والمطورين للتفاعل مع محتواهم.

بينما تم إنشاء WordPress على PHP - وسيستمر بناؤه على - PHP ، فإن WP REST API هي محاولة لإنشاء جسر بين تراث PHP WordPress الأساسي وإمكانات وقوة تطبيقات الويب JavaScript ، بالإضافة إلى الهاتف المحمول الأصلي وتطبيقات سطح المكتب.

تجلب واجهة برمجة تطبيقات WordPress REST محتوى أي موقع ويب WordPress إلى واجهة برمجة تطبيقات يسهل استهلاكها ، مما يسمح لـ WordPress بالعمل كنظام تخزين واسترجاع لنشر المحتوى على الويب.

إحضار REST API إلى WordPress

إذا كنت تعتقد أن WP REST API ظهرت من العدم ، فأنت مخطئ.

إن إضافة ميزة جديدة تمامًا إلى WordPress ليست مهمة سهلة. نظرًا لكونه برنامجًا مفتوح المصدر ، فإن تطوير WordPress يعتمد على المجتمع ككل لإحراز تقدم.

بدأ تطوير واجهة برمجة التطبيقات منذ بضع سنوات كمكوِّن إضافي منفصل للميزات ، مما سمح للمطورين بتجربة المشروع والمساهمة فيه في بيئة محكومة.

خلال العديد من التكرارات والتحسينات ، وإصدارين منفصلين تمامًا ، كان على المساهمين وراء REST API اختبار وتقييم الفوائد والعواقب الهائلة لتوفير وصول مفتوح لواجهة برمجة التطبيقات إلى البيانات الموجودة على عشرات الملايين من مواقع الويب.

جلب WordPress 4.4 ، الاسم الرمزي "Clifford" البنية التحتية الأولية للمشروع إلى نواة WordPress ، بينما لم تظهر نقاط النهاية حتى WordPress 4.7 ، "Vaughan".

بشكل أساسي ، أتاح هذا للمطورين الوقت لاختبار الوظائف التي تشغل واجهة برمجة التطبيقات دون الكشف الفعلي عن البيانات نفسها.

الآن بعد أن تم دمج نقاط نهاية المحتوى الأولية في جميع الإصدارات الحالية من WordPress ، يمكن لمطوري المكونات الإضافية ومؤلفي السمات تجربة طرق جديدة ومثيرة لاسترداد البيانات وعرضها وتغييرها خارج تجربة wp-admin التقليدية.

فصل الاختصارات: من HTTP إلى واجهة برمجة تطبيقات JSON REST

لفهم أهمية WP REST API ، قد يكون من المفيد فهم الأساس لكيفية مشاركة البيانات عبر الإنترنت وإلى أين يمكن أن تتجه الإنترنت.

HTTP هو الأساس لمعظم زيارات الويب التي نتعامل معها يوميًا. إذا قمت بكتابة عنوان URL في متصفح ، فأنت تقدم طلبًا . يتلقى الخادم المقابل طلبك ويقدم ردًا . هذه المعاملة هي أساس كل شيء نقوم به على الإنترنت تقريبًا. تقدم المستعرضات الطلبات ، وتقدم الخوادم ردودًا.

يمكن أن يؤثر نوع الطلب الذي نقدمه على نوع الاستجابة التي نحصل عليها. في معظم الأوقات ، نتقدم بطلب بسيط للحصول على GET : "مرحبًا Google ، احصل على صفحتك المقصودة." تقدم Google ردًا.

نظرًا لأن الويب أصبح أكثر تفاعلًا ، بدأنا في الاستفادة من طلبات HTTP الأخرى ، بما في ذلك PUT و POST و DELETE .

على سبيل المثال ، نقوم بملء شريط البحث على أحد مواقع الويب: "مرحبًا Google ، انشر عنوان بريدي الإلكتروني وكلمة المرور في صفحة تسجيل الدخول الخاصة بك." تبدأ Google جلسة جديدة لنا وتقدم ردًا مختلفًا.

هذا البروتوكول هو الأساس الأساسي الذي نبني عليه مواقع WordPress الخاصة بنا.

نحن نستخدم النماذج و PHP للحصول على البيانات و POST في قاعدة بياناتنا. على عكس الرأي السائد ، لن يتغير هذا الأساس الأساسي لـ WordPress في أي وقت قريب. كل ما يفعله WordPress الآن هو تزويد المطورين بطريقة جديدة للتفاعل مع بيانات WordPress الخاصة بهم عبر واجهة برمجة تطبيقات RESTful.

نقل الدولة التمثيلي (REST)

يجب أن يكون مطورو WordPress على دراية بواجهات برمجة التطبيقات بشكل عام ، مثل Shortcode API و Options API. تحدد واجهات برمجة التطبيقات هذه وظائف المكونات التي يتألف منها WordPress ، لذلك يمكن لمؤلفي السمات والمكونات الإضافية توسيع القدرات الأساسية لـ WordPress. ومع ذلك ، فإن واجهة WP REST API مختلفة قليلاً.

تدور واجهة برمجة تطبيقات REST أو RESTful حول تعريض بياناتك بشكل آمن لطلبات HTTP من مصادر خارجية. يتعلق الأمر أيضًا بإعداد بنية مشتركة ومجموعة من البروتوكولات للاستجابة لتلك الطلبات. في حين أن هناك المزيد من الأفكار والمبادئ المتقدمة وراء هذا النوع من الخدمة ، إلا أنها خارج نطاق هذا المقال.

إن وجود WP REST API ، خاصة بعد WordPress 4.7 ، يعني أن كل محتوى موقعك ، بما في ذلك المنشورات والصفحات والتعليقات وأي منشورات عامة ، يمكن الوصول إليها الآن مباشرة كبيانات أولية. هذا يعني أيضًا أنه يمكنك إجراء تغييرات على هذه البيانات من خارج wp-admin التقليدي إذا كنت ترغب في ذلك ، ربما من خلال تطبيق جوال أو سطح مكتب.

بدلاً من التفكير في بياناتك على أنها مجرد صفوف في قاعدة بيانات ، يمكنك الآن الوصول المتسلسل إليها في شكل JSON.

JSON - ماذا حدث لـ XML؟

يتمتع الأطباء البيطريون في WordPress بخبرة كبيرة في استخدام XML ، وهو تنسيق شائع لمشاركة المحتوى بين المواقع.

على غرار XML ، فإن JSON هي ببساطة آلية تسمح لنا بنقل البيانات بسهولة عن طريق تجميعها في صيغة محددة. JSON هي في الواقع سلسلة ، تمثيل نصي لكائن JavaScript ، تخزن بياناتك في مجموعة من أزواج المفتاح والقيمة. قد يبدو تمثيل JSON الشائع لمنشور WordPress كما يلي:

 { “id”: 1, “title”: { “rendered”: “Hello World” }, “content”: { “rendered”: “Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!” } }

(يمكنك استخدام أداة تنسيق JSON لتجميل استجابة JSON إذا لزم الأمر.)

ستتضمن استجابة JSON الكاملة عبر WP REST API معلومات إضافية حول المنشور ، بما في ذلك البيانات الوصفية. من خلال تجميع هذه البيانات بسهولة في تنسيق JSON ، يمكنك التفاعل مع محتوى WordPress الخاص بك بطرق جديدة ومثيرة.

ليس من قبيل المصادفة أن يتم إقران JSON بشكل أفضل مع JavaScript. مع بدء المزيد من مطوري WordPress في "تعلم JavaScript بعمق" ، سنرى المزيد والمزيد من الاستخدامات المتقدمة لـ WordPress كخلفية.

كيف نعثر على البيانات: اتبع الطريق إلى نقطة النهاية

الوصول إلى جميع بيانات موقعك عبر واجهة برمجة تطبيقات REST أمر بسيط مثل إنشاء عنوان URL.

بالنسبة إلى أي موقع WordPress يعمل بالإصدار 4.7 على الأقل ، أضف السلسلة التالية إلى نهاية عنوان url لموقعك: /wp-json/wp/v2 (على سبيل المثال ، http://example.com/wp-json/wp/v2 ). ضع عنوان URL هذا في متصفحك ، وشاهد ما سيحدث.

من المحتمل أن تبدو النتيجة فوضى كبيرة في البيانات ، إلا إذا قمت بتثبيت امتداد متصفح يقوم بتنظيف JSON. هذه الفوضى الكبيرة من البيانات هي المحتوى والمعلومات الوصفية لموقع WordPress الخاص بك بتنسيق JSON.

عن طريق تحميل هذا المحتوى ، تكون قد حددت للتو مسارًا وطلبت من المتصفح الحصول عليه لك.

المسار هو عنوان URL يتم تعيينه لطريقة معينة. يقرأ قلب WordPress هذا المسار ، حيث تمثل كل شرطة مائلة '/' مسارًا معينًا ، أو معلمة ، يجب اتباعها.

ينتهي المسار عند نقطة نهاية ، حيث يمكن للوظائف العميقة داخل نواة WordPress اتخاذ قرارات بشأن البيانات التي يجب تقديمها وما يجب فعله بأي بيانات تم توفيرها.

قد تكون نقطة نهاية المثال "/ wp-json / wp / v2 / posts / 1" ، حيث أضفنا المسارات '/ posts' و '/ 1'. تخبر نقطة النهاية الخاصة هذه موقعنا بالمرور عبر بياناتنا ، وسحب منشوراتنا ، وسحب المنشور بمعرف 1.

ما يجعل REST API مفيدة للغاية هو حقيقة أنها قابلة للتوسيع ، مما يعني أنه يمكنك أخذ أي بيانات داخل موقع الويب الخاص بك وإضافتها كنقطة نهاية. يتم دعم معظم وظائف WordPress الأساسية حاليًا (أو سيتم دعمها قريبًا).

ومع ذلك ، يمكن لمطوري السمات والمكونات الإضافية البدء في إضافة المحتوى والإعدادات المخصصة الخاصة بهم كنقاط نهاية ، مما يسمح للمستخدمين بالتفاعل مع مواقع الويب الخاصة بهم بطرق جديدة.

إذا كنت مهتمًا بنقاط النهاية المتوفرة حاليًا على موقع WordPress الخاص بك ، فإن تطبيق متصفح مثل Postman يوفر واجهة مستخدم رسومية خصيصًا لاستكشاف واجهات برمجة التطبيقات.

الرؤوس والمصادقة

تبدو كتابة نقاط نهاية URL في المتصفح أمرًا بسيطًا ، لكنها تتضمن في الواقع مجموعة من الرؤوس الافتراضية جنبًا إلى جنب مع الطلب. في المقابل ، يتم أيضًا إرسال مجموعة من الرؤوس مع الاستجابة. تتضمن هذه الرؤوس الكثير من المعلومات المفيدة ، ولكن أهمها لأغراضنا تتعلق بنوع الطلب الذي نتقدم به وما إذا كنا قد تمت مصادقتنا أم لا.

إذا انتقلت إلى "أدوات المطور" في متصفحك ، فيمكنك فحص رؤوس HTTP لأي أصل يتم تحميله في نافذة المتصفح ، بما في ذلك ملفات HTML وأوراق أنماط CSS والصور والمزيد.

العنوان الأول الذي يجب مراعاته هو طريقة الطلب ، والتي تتوافق مباشرة مع طلبات HTTP التي تعلمنا عنها سابقًا. هنا سترى على الأرجح GET كطريقة طلب ، إذا كنا ببساطة نستعرض الصفحة.

قد يختار التطبيق الذي يستدعي REST API تغيير طريقة طلب العنوان إلى POST.

تخبر طريقة POST موقع الويب الخاص بك بإدخال بيانات جديدة أو تغيير البيانات الموجودة في قاعدة بيانات WordPress الخاصة بك. من خلال إرسال المعلومات من خلال طريقة POST ، تتمتع التطبيقات الأخرى بالقدرة على تغيير بياناتك ، دون تسجيل الدخول إلى wp-admin.

ومع ذلك ، لا داعي للقلق ، لأنه ما لم تتضمن أيضًا رؤوسًا توفر بيانات الاعتماد المناسبة للمصادقة ، فسيقوم موقع الويب الخاص بك برفضها.

ملاحظة: لا تزال طرق مصادقة المكالمات إلى واجهة برمجة تطبيقات REST الخاصة بك غير نهائية ، على الرغم من ذلك ، مما يجعل المصادقة أكبر عائق أمام دخول المطورين الراغبين في العمل مع واجهة برمجة تطبيقات REST لإضافة البيانات أو تغييرها.

في الوقت الحالي ، هناك خيارات متاحة ، بما في ذلك مكون إضافي من المطورين وراء REST API. نظرًا لأن الإجراءات القياسية المحيطة بالمصادقة تشق طريقها إلى جوهرها ، فستكون العقبات الأخيرة واضحة للاستخدام الواسع النطاق لـ WP REST API.

تطبيق نموذج WP REST API

ما يجعل WP REST API قوية للغاية هو حقيقة أنها متسقة ، لذلك يمكننا أن نتوقع نفس النتائج الأساسية من أي موقع يقوم بتشغيل WordPress 4.7 أو أعلى. ومع ذلك ، فإن WordPress عبارة عن واجهة برمجة تطبيقات موزعة ، مما يعني أنه لا يوجد مكان واحد فقط للحصول على جميع البيانات منه.

كل موقع ويب يقوم بتشغيل WordPress هو تطبيق فريد من نوعه ، مع مستخدمين ومصادقة فريدة. على الرغم من أن تحرير المحتوى من خلال واجهة برمجة تطبيقات REST قد يتطلب تقنيات ترخيص مميزة ، إلا أنه يمكننا الوصول إلى منشورات معظم المدونات التي يديرها WordPress بسهولة تامة.

للتوضيح ، سنقوم بعمل عرض توضيحي سريع للكود يقوم بتحميل مقتطفات من أحدث المنشورات من بعض المدونات ذات الصلة بـ WordPress والتي تعمل جميعها بالطبع على WordPress. أثناء تواجدنا فيه ، سنقوم بتضمين نموذج بحث ، حتى نتمكن بالفعل من البحث في كل هذه المواقع مرة واحدة ، وسحب المقالات ذات الصلة من كل منها.

أخيرًا ، سنحرص على تضمين الرابط لقراءة نص المقالة بالكامل على موقع الويب الأصلي.

المرحلة 1: الحصول على المشاركات الأخيرة

سنبدأ بإعداد مثيل Vue سريع وتثبيته على عنصر. سنقوم أيضًا بتضمين Bootstrap حتى نتمكن من الحصول على شبكة وتصميم أساسي على عناصر النموذج التي سنضيفها لاحقًا.

عندما نحدد البيانات ، سنريد مكانًا لتخزين اسم الموقع (الذي لم يتم تضمينه في الاستجابة الافتراضية) وعنوان URL والمنشورات بمجرد حصولنا عليها. هذا مثال:

 { “name”: “wordpress.org”, “url”: “https://wordpress.org/news/wp-json/wp/v2/posts?per_page=3”, “posts”: [] }

ستلاحظ أننا قمنا أيضًا بتضمين per_page . عادةً ، ستقوم WP REST API بتقسيم النتائج باتباع نفس القواعد كما لو كانت ترقيم حلقة WP_Query عادية. سنقتصر استفساراتنا على المشاركات الثلاثة الأولى.

بعد ذلك ، سنقوم بتعريف طريقة loadPosts() ، والتي ستنقل عبر قائمة المصادر لدينا ، وتحصل على النتائج باستخدام vue-source ، وتعبئ مصفوفة posts الفارغة لكل مصدر بالنتائج.

 loadPosts : function(){ var self = this; self.sources.forEach(function(source, index){ self.$delete(source, 'posts'); // Get API with vue-resource self.$http.get(source.url).then(function(response) { self.$set(source, 'posts', response.data); }, function(response) { console.log('Error'); }); }); }

سنقوم أيضًا بتضمين استدعاء أولي لـ loadPosts() عندما يتم تثبيت مثيل Vue الخاص بنا بنجاح.

 mounted : function(){ this.$nextTick(function(){ // Load posts on initial page load this.loadPosts(); }); }

سيكون الاحتفاظ loadPosts() كطريقة منفصلة مفيدًا في المستقبل حيث نبدأ في إجراء مكالمات متعددة إلى API. في HTML الخاص بنا ، سنستخدم توجيهات عرض قائمة Vue البسيطة وبناء جملة القالب لإخراج جميع منشوراتنا.

شاهد القلم المضمن للحصول على عرض توضيحي عملي:

انظر مثال بحث Pen WP REST API (المرحلة الأولى) بواسطة Brian Coords (@ bacoords) على CodePen.

المرحلة الثانية: تصفية النتائج

دعنا نضيف شريطًا جانبيًا ، وننشئ بعض المرشحات لإظهار / إخفاء المصادر المختلفة. للقيام بذلك ، نضيف خاصية جديدة إلى كائن sources ، قيمة منطقية سنسميها.

أثناء قيامنا بإضافة عوامل تصفية ، دعنا ننشئ مرشح Vue لمساعدتنا في عرض التاريخ بشكل صحيح أيضًا. يخزن WordPress تاريخ ووقت المنشور كطابع زمني لنظام Unix.

سنستخدم مكتبة الجهات الخارجية Moment.js لتحويل التاريخ إلى تنسيق أكثر قابلية للقراءة.

 filters: { // Using Moment.js to convert post date to a readable format prettyDate: function(value){ // Return if date is empty if(!value) return ''; // Convert date to Moment.js var date = moment.utc(value); // Return formatted date return date.format("MMM DD, YYYY,"); } },

شاهد القلم المضمن للحصول على عرض توضيحي عملي:

انظر مثال بحث Pen WP REST API (المرحلة الأولى) بواسطة Brian Coords (@ bacoords) على CodePen.

المرحلة النهائية: استعلامات البحث

سنضيف هنا معاملاً جديدًا إلى طلب API الخاص بنا. لقد أضفنا بالفعل المعلمة per_page=3 للحد من عدد النتائج التي نحصل عليها من كل موقع. إذا كان هناك أي شيء مكتوب في شريط البحث ، فسنضيفه كمعامل إضافي.

سيسمح لنا ذلك باستخدام وظيفة البحث المضمنة في كل موقع ، تمامًا كما لو كنا نستعلم عن شريط البحث على هذا الموقع.

سنقوم بإضافة شريط بحث ، وربطه بمتغير باستخدام توجيه Vue's v-model .

بدلاً من استدعاء جميع واجهات برمجة التطبيقات على الفور ، عندما يبدأ المستخدم في الكتابة ، سنضيف زرًا ونربط حدثًا بإرسال النموذج. ثم سنضيف طريقة إلى مثيل Vue الخاص بنا والتي تضيف معلمات البحث (عنوان URL المشفر بالطبع) إلى عنوان URL.

 generateUrl : function(source){ var self = this; // Add search parameters. if(self.searchQuery){ return source.url + '&search=' + encodeURI(self.searchQuery); }else{ return source.url; } }

شاهد القلم المضمن للحصول على عرض توضيحي عملي:

انظر مثال بحث Pen WP REST API (المرحلة الأولى) بواسطة Brian Coords (@ bacoords) على CodePen.

في حين أن هذا مثال بسيط على WP REST API ، يمكننا تخيل تطبيق محتمل لشيء مثل هذا داخل WordPress نفسه. على سبيل المثال ، هناك بالفعل مربع تعريف "أخبار WordPress".

يمكننا بسهولة تحويل هذا العرض التوضيحي إلى مكون إضافي لبرنامج WordPress ، وعرضه على لوحة معلومات WordPress. لقد قمنا الآن بدمج القدرة على البحث عن المساعدة من بعض أفضل مواقع WordPress والبرامج التعليمية لتصميم الويب مباشرةً من موقع الويب الخاص بنا.

الإمكانات المستقبلية لـ REST API

على الرغم من أن المثال أعلاه لا يخدش سوى سطح إمكانيات WP REST API ، إلا أنه يجب أن ينقل بعض الاحتمالات التي تبدأ في الظهور عندما تبدأ في اللعب بالبيانات. سواء تم استخدامه لتحسين تجربة المستخدم على موقع الويب نفسه ، أو لجمع البيانات ومعالجتها من مصدر خارجي ، فهي أداة قوية.

بينما أعرب بعض خبراء الصناعة عن مخاوفهم بشأن إمكانية "كشط" المحتوى الخاص بك وعرضه في مكان آخر ، فمن المهم أن تتذكر أن هذه الوظيفة مشابهة لموجزات RSS ، ومن الضروري أن يتحكم مشرفو الموقع بشكل واضح في ماهية البيانات وما هي لا الجمهور.

نظرًا لأن WP REST API أصبحت أكثر ترسخًا في نسيج WordPress ، فسنبدأ في رؤية آثارها ، ربما دون أن ندرك ذلك. وقد تراوحت الأمثلة من التطبيقات البسيطة (اقتباسات كريس كويير عن التصميم) إلى التطبيقات المعقدة ذات الصفحة الواحدة (موقع غوغنهايم).

حالة الاستخدام الشائعة الأخرى لـ WP REST API هي تطوير تطبيقات الهاتف المحمول.

نظرًا لأنه يمكن الوصول إلى المحتوى من خلال REST API ، يمكن للمطورين إنشاء تطبيقات أصلية لنظامي التشغيل iOS و Android ، وتجنب الاضطرار إلى إنشاء مصادر بيانات مكررة.

عندما يتفاعل المستخدمون مع تطبيقات الأجهزة المحمولة هذه ، سيكونون قادرين على استرداد بيانات موقع الويب الأصلي وتحويلها مباشرةً ، دون أن يضطر المطور إلى إنشاء أي بنية تحتية معقدة لدعم ذلك.

ومع ذلك ، فإن هذه التطبيقات التي تواجه الزائرين لواجهة برمجة تطبيقات REST ليست سوى البداية ، حيث أن الآثار الحقيقية أعمق بكثير. أحد أهداف فريق التطوير الأساسي هو البدء في استخدامه عبر واجهة wp-admin.

مع تحديثات WordPress المستقبلية ، سنبدأ في استبدال admin-ajax لصالح API ، ونأمل أن تزيد سرعة الوظائف الأساسية ، مثل تحرير القوائم أو نشر المنشورات.

يمكن أن يسير هذا جنبًا إلى جنب مع تركيز WordPress المتزايد على Customizer والمحرر كنقاط انطلاق سهلة الاستخدام لمبتدئين في WordPress.

في حين أن WP REST API مفيدة للغاية كما هي ، لا يزال هناك المزيد مما يجب القيام به. API ليست كاملة. لا يزال هناك المزيد من الميزات ونقاط النهاية لإضافتها.

في النهاية ، ستتمكن من التفاعل مع موقع WordPress الخاص بك دون حتى زيارته. وبينما تستخدم العديد من الخدمات الآن واجهات برمجة تطبيقات مخصصة للتفاعل مع WordPress ، فإن الانتقال إلى واجهة برمجة تطبيقات WordPress REST قياسية واحدة يعني أن المزيد من المواقع والخدمات يمكن أن تتواصل وتتحدث بنفس اللغة.

بدأ WordPress كمنصة تدوين ، وهي وسيلة للمدونين للتواصل ومشاركة أفكارهم وأفكارهم. مع تطوير WordPress REST API ، سنبدأ في رؤية مستوى جديد من الاتصال والمشاركة خلف الكواليس. سيسمح هذا للمستخدمين بالبناء على أفكارهم وأفكارهم بطرق لم يسبق لها مثيل ، مع نقل WordPress ومستخدميه إلى آفاق جديدة تمامًا.