لوحة المتصدرين

توجد وظيفة جديدة في الساحة التقنية، قد لا تكون جديدةً بالمعنى الحرفي للكلمة، ولكنها بالتأكيد تظهر بوتيرة متزايدة، فالعديد من عمالقة التقنية، مثل: Google، وAmazon، وDropbox، وPaypal، يبحثون عن كُتّاب لتجربة المستخدِم UX Writers. قد يبدو الأمر وكأنه صيحة عابرة هادئة لاضجيج لها، لكن كُتّاب تجربة المستخدِم سيكونون جزءًا مهمًا من الأسلوب الذي نصمم به تجارب المستخدِم من الآن فصاعدًا. أحب متابعة إعلانات الوظائف التي تطلبها الشركات في مدينتي، فقط لأرى ما هي الأولوية التي تعطيها شركات التقنية الكبرى. ففي عام 2016، رأيت عددًا كبيرًا من الإعلانات من شركات، مثل: Amazon، وGoogle، وبعض الشركات الأصغر حجمًا في عالم التقنية، وكلها تبحث عن كُتّاب لتجربة المستخدِم. كوني كاتبًا صادف مجال الكتابة لتجربة المستخدِم منذ عدة سنوات، فقد كنت متحمسًا لأن المؤسسات والشركات قد أخيرًا أدركت أن الكتابة التسويقية لا يجب أن تكون حكرًا فقط على أخصائي التسويق. لقد مرت بفكري كل الكتابة الخاصة بواجهة المستخدِم والدعوة إلى الإجراء -وهو أسلوب تسويقي على الويب يهدف إلى دعوة المستخدِم لإتمام فعل تسويقي معيّن-، وكل المقاطع النصية الصغيرة التي عملت عليها على مرّ السنين مع العديد من الفُرق والأشخاص، كل ذلك جعلني أشعر بالرضا لأن زمن كُتّاب تجربة المستخدم قد حان. لكن بعد ذلك أدركت أنّ كتابة تجربة المستخدم هي أكثر من مجرد كتابة، إذ أن واقع تصميم تجربة المستخدم اليوم هو أنّ تجاربنا مع التقنية أصبحت أكثر اندماجًا مع حياتنا بسلاسة أكثر. فاليوم يمكنك التحدث إلى الآلات لطلب البقالة -على الأقل حيث أعيش بسياتل أمريكا-. حيث نطلب من روبوت مبرمَج على الهاتف التحقق من أرصدة حساباتنا البنكية، كما يمكننا تشغيل لعبة فيديو عن طريق الطلب من XBox. وفي الواقع الافتراضي Virtual Reality حيث لا يمكننا لمس أي شيء، فيمكن لأصواتنا أن تفعل ما قد لا تستطيع أيدينا القيام به. هناك قدر متزايد من التداخل بين واجهات المستخدم الرسومية GUI وواجهات المستخدم الصوتية VUI، مما يستلزم مجموعة مهارات جديدة، مثل تمتُّع محترفي تجربة المستخدِم بفهم عميق للتصميم المحكي Narrative design، والتصميم التخاطبي Conversational design. دعنا نلقي نظرةً على ماهية الكتابة لتجربة المستخدِم (وما هي ليست كذلك)، وما الذي تبحث عنه الشركات في هؤلاء الكُتّاب، وأفضل الممارسات العامة في هذا المجال. ما هي الكتابة لتجربة المستخدم؟ لقد أمضيت الأشهر القليلة الماضية أشعر بفضول عميق حول هذا الدور الناشئ لكاتب تجربة المستخدِم؛ لقد كنت أجمع توصيفات وظيفية، وأجري مقابلات مع كتّاب حاليين لتجربة المستخدم، في محاولة فهمها وأنا سعيد بما تعلمت. استنادًا إلى بحثي حول التوصيفات الوظيفية وحديثي مع كُتاب تجربة المستخدم الذين يعملون في الميدان، فقد وجدت أنّ كتابة تجربة المستخدم هي -في أبسط صورها- عملية الكتابة عن نقاط التواصل التي تَظهر للمستخدِم ليتفاعل مع التقنية التي يستخدمها. بحيث لا تمثل هذه الكتابة صوت الشركة الصانعة فحسب، بل يجب أيضًا أن تكون مراعيةً ومفيدةً للمستخدم. في الماضي، على سبيل المثال، قرر أحد كُتّاب تجربة المستخدم الجيدين -الذي لم يكن عمله الأساسي كاتبًا لتجربة مستخدم، بل ربما كان ماهرًا في الأمر فحسب- أنه عندما يرسل المستخدم رسالةً إخباريةً جماعية باستخدام بريد MailChimp وهو البريد الإلكتروني الخاص بالتسويق، فمن المحتمل أن يكون في حالة من القلق البسيط من إمكانية عدم نجاح الأمر. ولجعل المستخدمين يشعرون بالثقة بشأن نجاح عملية الإرسال، فقد صمم فريق MailChimp رسالة نجاح تُهنئ المستخدم بنجاح إرسال ما أرسله للتو بدلًا من مجرد الإبلاغ عن حالة الارسال التقليدية. بعد البحث في بضع عشرات من التوصيفات الوظيفية لمنصب كاتب تجربة المستخدم، فستكون ثمة بعض المسؤوليات المشتركة فيما بينها بالتأكيد، ومنها: البحث يبدو أن كُتّاب تجربة المستخدم هم أعضاء بارزون في فريق تصميم تجربة المستخدم في جميع المجالات، ومن المتوقع أن يُجْروا أو يشاركوا في الأبحاث المتعلقة بالمستخدم والجمهور، على أساس جزء من عملية التصميم التي تركز على المستخدم. في ما يلي مثال من وصف وظيفي لأحد الشركات التقنية: الكتابة طبعا لا ينبغي أن يكون هذا مفاجئًا، لكن الكتابة أمر أساسي جدًا لعمل كاتب تجربة المستخدم، ونحن لا نقصد عندما تقول عن نفسك "يقول لي الناس إنني كاتب جيد جدًا". نحن نقصد عندما تقول "يخبرني الناس أنني كاتب عظيم، ويمكنني شرح كل كلمة من اختياراتي وأدافع عنها حتى الموت". تشير جوجل إلى فريق كُتاب تجربة المستخدم الخاص بها باسم "صانعو الكلمات المناوبون" نسبةً إلى الأطباء المناوبين في المشافي. وإليك مثال عن التوصيف الوظيفي لكاتب تجربة المستخدم في إعلانات أمازون: التعاون لست متأكدًا من أنني سأعد هذا الأمر مهمًا جدًا لهذا العمل، ولكن معظم التوصيفات الوظيفية تستدعي التعاون بين الفرق كونه مسؤوليةً مهمةً في كتابة تجربة المستخدِم. من المحتمل ألا يكون هذا الأمر مفاجئًا لأي شخص عمل مثل كاتب مخضرم في أي مجال كان، لكن بالنسبة لي أعتقد أنّ لكل شخص رأي في الكلمات التي يكتبها. وفيما يلي مثال من إحدى إعلانات التوظيف: هناك أيضًا بعض المسؤوليات التي قد تظهر فجأةً هنا وهناك، ولكنها من غير المتوقع أن تواجهها دائمًا، وهي تشمل ما يأتي: بناء وتنفيذ استراتيجية التحرير. بناء وتنفيذ استراتيجية المحتوى. أن تكتب كتابةً تسويقية. كتابة مواد تدريبية سهلة الاستخدام. من خلال جميع التوصيفات الوظيفية التي درستها، يبدو أنّ هذه المسؤوليات الأخرى غير المرتبطة بمهام كاتب تجربة المستخدِم تظهر لعدد من الأسباب. وقد يكون أحد هذه الأسباب هو أنّ الشركات لا تستطيع تبرير توظيف شخص يكتب عن واجهة المستخدم فقط، وتبحث بدلًا من ذلك عن فريق متعدِّد الوظائف ليمكنها من خلاله ضرب عصفورين بحجر واحد، إذا جاز التعبير؛ في حين قد يكون السبب الآخر هو الافتقار إلى فهم المهارات التي تنطوي عليها الكتابة بالموازنة مع استراتيجية المحتوى، والكتابة موازنةً مع الخبرة التحريرية، وما إلى ذلك. وفي كلتا الحالتين، فمن الواضح أنه من الأفضل أن تكون متعدِّد المهارات لتنال فرصةً في التوظيف. من المهم أيضًا التفريق بين كتّاب تجربة المستخدم وبين الكتاب الآخرين. وبما أنه لا يوجد الكثير من التدريبات الأكاديمية لتعلم كتابة تجربة المستخدم، فمن المحتمل أن يكون كاتب تجربة المستخدم الجيد متعدد الوظائف. ومع ذلك، فلا ينبغي الخلط بين مهام كاتب تجربة المستخدِم والمهام التالية: الكاتب التقني: الذي يكتب عن التقنية بهدف التوضيح والتدقيق، وليس بهدف الكتابة عن التجربة. اخصائي استراتيجية المحتوى: الذي يخطط للمحتوى على نطاق واسع، وليس بالضرورة من يكتبه. مهندس المعلومات: الذي يركز على هياكل وتصنيفات المعلومات المستدامة، ويبنيها. أخصائي التسويق: الذي يركز على الاستراتيجيات والحملات التي تهدف إلى جذب أشخاص جدد إلى منتج أو خدمة ما. ما الذي تبحث عنه الشركات في كتاب تجربة المستخدم؟ حسنًا، نحن الآن نعرف مهام كُتّاب تجربة المستخدم، ولماذا سيصبح هذا الدور مهمًا باستمرار. دعنا نلقي نظرةً على بعض الصفات الشاملة التي تبحث عنها الشركات في كُتّاب تجربة المستخدم الطموحين. مستوى تعليمي في مجالات التواصل يُعَدّ هذا الأمر تقريبًا مطلبًا عالميًا. حيث تبحث الشركات التي توظف كُتّاب تجربة المستخدم عن أشخاص تلقوا تدريبًا رسميًا في الصحافة، والكتابة الفنية، والكتابة الإبداعية، وفن التواصل، والعلاقات العامة، بمعنى أي شيء يتعلق على نحو مباشر بالكتابة.يُعَدّ هذا تحولًا مثيرًا للاهتمام بالنسبة لمصممي تجربة المستخدم التقليديين، حيث يُتوقع منهم فهمًا بديهيًا لكيفية تصميم التواصل الفعال بدلاً من تصميم واجهات المستخدم وحسب. لقد قابلت مجموعةً من كتّاب تجربة المستخدم على مدار العام الماضي، وكان لديهم إما خلفية تحريرية خاصة، مثل امرأة التقيت بها سابقًا كانت تعمل محررة علوم لـدى موسوعة مايكروسوفت الشهيرة Microsoft Encarta؛ أو خلفية صحفية مثل أحد الكُتّاب لدى Google UX، والذي كان صحفيًا تقنيًا فيما سبق. قدرات كتابية مذهلة وإثبات ذلك تبحث الشركات التي تُجري المقابلات لتوظيف كاتب تجربة المستخدِم عن الكُتاب الذين يمكنهم شرح اختياراتهم كما يفعل المصممون عند عملهم؛ أي إذا اختار الكاتب كلمةً ما في كتابته، فيجب أن يكون قادرًا على تبرير اختياره، بحيث يدعم ذلك بالأبحاث عن سبب كون هذه الكلمة اختيارًا أفضل من الأخرى. سأستخدم رسالة نجاح عملية الإرسال في خدمة MailChimp مثالًا لذلك، ربما سُئل هذا الكاتب في وقت ما، "لماذا استخدمت تعبير High five - كفك!"، وهو تعبير يعبِّر عن الاحتفال عوضًا عن "رسالتك الإخبارية في طريقها"؟ وربما أجاب هذا الكاتب بشيء ،مثل: "حسنًا، لأنه في بحثنا المتعلِّق بالمستخدم، اكتشفنا أن المستخدِمين غالبًا ما يكونون قلقين بدرجة معتدلة وغير متأكدين مما أرسلوه للتو، وبالنظر إلى أسلوب عملنا في شبكات التواصل الاجتماعي، فإن تعبير High five هو أكثر ملاءمةً لجعلهم يشعرون بمزيد من الثقة فيما أنجزوه للتو". هذا مثال افتراضي، لكنه يوضِّح وجهة نظري. أي إذا أجرى كاتب تجربة المستخدم مقابلة توظيف مع شركة ما، فيجب أن يتوقع أن يُطلب منه بصورة صريحة تبرير اختياراته للكلمات والتعابير التي استخدمها، سواءً كانت في مقطع نصي طويل، أو كلمة واحدة في شريط الانتقال. المرونة وروح المبادرة يُعَدّ عمل كاتب تجربة المستخدِم أمرًا حديثًا، وربما لم توضحه العديد من الشركات حتى الآن. وهو الأمر الذي يدفعنا إلى قول أنه يتعين على كتّاب تجربة المستخدم التحلي بالشجاعة، والعمل بطريقة متكيفة في بيئة رشيقة، وربما قد يتعين عليهم تحديد مسؤوليات أدوارهم بأنفسهم، وإنجاز مهام متعددة الوظائف قد لا ترتبط بصورة وثيقة بمجالهم، مثل: إنشاء مخطط شبكي Wireframe لموقع ويب ما، أو تطوير إرشادات صوتية، أو تخطيط استراتيجيات التحرير، وعليهم أن يفعلوا ذلك على نحو فعّال. بعبارة أخرى، يسير كتّاب تجربة المستخدم في بيئة لا يوجد فيها شيء مؤكد، لذلك يتعين عليهم أن يكونوا قادرين على أداء وظائفهم على نحو جيد، مع دفاعهم عن أهمية دورهم في عملية تصميم تجربة المستخدم. ترجمة وبتصرّف للمقال ?What is UX Writing لصاحبته Kristina Bjoran.

أصبحت واجهات REST البرمجية أكثر انتشارًا بين المطوّرين، نظرًا لأنها توفّر واجهة بسيطة، موحّدة وواضحة لخدمات الطرف الثالث third-party مثل Twitter، MailChimp وGitHub. ومع ازدياد شهرة واجهة ووردبريس البرمجية (المتوفرة عبر إضافة) فإن الوقت قد حان لنتعلم حول واجهة HTTP البرمجية في ووردبريس، وكيفية عملها واستخداماتها. ما هي واجهة HTTP في ووردبريس؟ لن يكون من المستغرب القول بأنها طريقة لإرسال واستقبال الرسائل بواسطة HTTP – لغة شبكة الويب. حيث يقوم المتصفح بإرسال واستقبال الرسائل طوال الوقت وبهذا الشكل يتم استقبال صفحات الويب. ويمكن من خلال واجهة REST البرمجية، يمكن باستخدام رسائل HTTP القيام بأشياء أكثر كتعديل منشور، حذف حساب مستخدم أو نشر وصفة جديدة على موقعك. لهذا السبب تعتبر واجهة ووردبريس البرمجية مهمة جدًا، فهي تسمح بفصل التطبيق من جهة المستخدم عن النواة البرمجية الخاصة بووردبريس. ولاستخدامها، تحتاج أن تكون معتادًا على إرسال طلبات HTTP واستقبال الأجوبة، وهذا هو أساس عمل واجهة HTTP البرمجية. وهناك العديد من الطرق لإرسال طلبات HTTP، حيث توفّر واجهة HTTP البرمجية طريقة موحّدة باستخدام مجموعة من التوابع المساعدة والتي سنطّلع عليها بعد قليل. طرق HTTP ومصادرها ترتكز HTTP حول الطرق methods (تسمّى أحيانًا بالأفعال verbs) والمصادر resources. تحدّد المصادر العنصر الذي سيتم تنفيذ العملية عليه، وتحدّد الطريقة نوع العملية التي سيتم تنفيذها. ويعتبر العنوان URL هو المصدر الذي يشير إلى الغرض على شبكة الويب، كمنشور على سبيل المثال. وتوجد العديد من الطرق، لكن الأهم فيها هي GET, POST, PUT و DELETE. ولا بد أن لديك الكثير من الخبرة مع GET فهذه الطريقة هي المستخدمة في الحصول على المصادر، فمثلًا عند استعراض مقال في المتصفح يتم إرسال طلب GET إلى عنوان المقال وليكن مثلًا https://premium.wpmudev.org/blog/using-the-wordpress-http-api/. أما طلبات PUT فتستخدم لتعديل المصادر، وتستخدم طلبات POST لإنشاء مصادر جديدة، وتستخدم طلبات DELETE لحذف مصادر موجودة مسبقًا. ولو كان لدى موقع WPMU DEV واجهة REST برمجية، فربما كان من الممكن أن يقوم المدير بإرسال طلب DELETE لحذف المقال على الرابط https://premium.wpmudev.org/blog/wordpress-http-api، وهذا الأمر مفيد جدًا للمواقع الكبيرة التي تملك برامج إدارة على الهواتف الذكية. مثال عن طلب HTTP بسيط للقيام بإرسال طلب GET بسيط على سبيل التجربة، سنقوم باستخدام التابع wp_remote_get() الذي يملك مُعاملين، المُعامل الأول هو رابط المصدر، والمُعامل الثاني هو مصفوفة اختيارية optional من الخيارات التي من الممكن استخدامها لتحديد بعض التفاصيل. $test = wp_remote_get( 'http://google.com' ); echo "<pre>"; var_dump($test); echo "</pre>"; يقوم المثال السابق بجلب الصفحة الرئيسية لموقع جوجل، ومن ثم يتم طباعة محتوى المتغير test الذي يحوي على جواب الطلب الذي أرسله موقع جوجل – حيث يمكن رؤية جميع العناصر التي يحتويها. تحتوي الترويسات headers على المزيد من المعلومات عن كل رسالة. وقد تطلب منك بعض واجهات REST البرمجية أن تقوم بإرسال معلومات محددة في الترويسات عندما ترسل الطلب. يحتوي الجواب response على رمز الحالة status code وعبارة قد تكون معروفة بالنسبة لك كأخطاء 404، أو خطأ في معالجة الطلب 500 أو تحويل من النوع 301 أو 302. يحتوي موقع W3.org على جميع رموز أخطاء HTTP المعرّفة والمشروحة، ويعتبر مصدرًا مفيدًا إن احتجت أن تعرف ما يعني أي خطأ. بإمكانك أيضا الاطّلاع على هذا المقال على أكاديمية حسوب لتعرف المزيد حول هذه الرّموز: رموز الإجابة في HTTP يحتوي الجسم body على الجواب وهو المكان الذي تحتاج أن تنظر إليه بحثًا عن النتيجة المطلوبة. في حالة المثال السابق، فإننا نحصل على وسوم HTML التي تشكّل الصفحة الرئيسية، ولكن عند التعامل مع واجهات REST البرمجية فمن الشائع أن نحصل على نص بصيغة JSON. وعادة ما تطلب الواجهات البرمجية APIs أن يتم إضافة نص محدّد إلى الجسم عند إرسال طلبات أيضًا. يحتوي قسم cookies على أي كعكات تم استلامها مع الرسالة. كما ترى، فإن إرسال طلب باستخدام واجهة HTTP البرمجية أمر بسيط جدًا. ما يجعل العمل مع HTTP معقّد نوعًا ما هو أن واجهات REST البرمجية قد تكون حساسة جدًا لصيغة البيانات المدخلة (وهو أمر جيّد) لذا فإن تجاوزت سطرًا عند دراسة توثيق الواجهة البرمجية قد ينتهي بك الأمر ببرمجية لا تعمل كما ترغب. العمل مع الواجهات البرمجية أعتقد بأنه من الآمن القول بأن معظمكم سيستخدم HTTP للتعامل مع واجهات REST البرمجية في شبكة الويب، وفي هذه الحالة سنحتاج لاستخدام المعامل الثاني لتحديد بعض الأمور، كالاستيثاق وتجنب بعض الأخطاء الشائعة. لنبدأ بمثال بسيط – استعادة البيانات من لوحة Pinterest. تتطلب جميع الواجهات البرمجية الجيّدة تنفيذ عملية استيثاق للتعريف عن المستخدم الذي يرسل الطلب، لكنّنا سنغش قليلًا في هذا المثال باستخدام مولّد رموز الأمان الخاص بـ Pinterest. بعد إكمال الاستيثاق ستحصل على رمز أمان يمكن استخدامه في المثال التالي، حيث سنقوم بإنشاء طلب لجلب وعرض قائمة بمنشورات Pinterest. $request = wp_remote_get( 'https://api.pinterest.com/v1/boards/marticz/home-office/pins/?access_token=<your access token>' ); $pins = json_decode( $request['body'], true ); if( !empty( $pins['data'] ) ) { echo '<ul>'; foreach( $pins['data'] as $pin ) { echo '<li><a href="' . $pin['url'] . '">' . $pin['note']. '</a></li>'; } echo '</ul>'; } لو قمنا بنسخ المثال السابق ولصقه في صفحة content-page.php في قالب Twenty Fifteen لتجربته فإن النتيجة هو الحصول على لائحة بالمنشورات من لوحة Pinterest حول المكاتب الشخصية في المنزل. لا تنس أن تستبدل <your access token> في المثال السابق برمز الأمان الذي حصلت عليه. يقوم السطر الثاني في المثال بفك ترميز جسم الجواب من JSON إلى شكله الأساسي كمصفوفة ونقوم بإنشاء حلقة loop تقوم بطباعة محتوى عنصر المصفوفة $pins['data']. الاستيثاق يقع العديد من الأشخاص في عثرات في هذه المرحلة لأنها تتطلب خطوة إضافية على الأقل وربما بعض الترويسات الإضافية أيضًا. ولننظر إلى واجهة تويتر البرمجية على سبيل المثال، وتحديدًا إلى الاستيثاق الخاص بالتطبيقات، الذي يمكنك استخدامه لاستيثاق تطبيقك مع تويتر. قراءة التوثيق إن أول خطأ قد يتم ارتكابه هو عدم قراءة التوثيق بشكل جيّد. ولو كنت مبرمجًا متمرسًا في واجهات REST البرمجية فيمكنك القفز مباشرة إلى الجزء حول الاستيثاق، ولو فعلت هذا فقد لا تنتبه إلى سطر يقول: وإهمال هذا الشرط سيؤدي إلى فشل حتمًا في الحصول على نتيجة، على الرغم من أن كل شيء آخر مطبّق بشكل كامل، لذا حتى توفّر على نفسك الحاجة لمراجعة شفرة برنامجك، تأكد من قراءة التوثيق بشكل جيّد وكامل. إضافة ترويسات ومعاملات أخرى بعد اتباع التوجيهات في التوثيق حرفيًّا، قمت بإنشاء طلب POST، ينبغي أن يؤدي إلى توليد رمز أمان للوصول من أجلي، ويبدو الكود على الشكل: $key = base64_encode( urlencode( "n8KP16uvGZA6xvFTtb8IAA:i4pmOV0duXJv7TyF5IvyFdh5wDIqfJOovKjs92ei878" ) ); $request = wp_remote_post('https://api.twitter.com/oauth2/token', array( 'headers' => array( 'Authorization' => 'Basic ' . $key, 'Content-Type' => 'application/x-www-form-urlencoded;charset=UTF-8' ), 'body' => 'grant_type=client_credentials', 'httpversion' => '1.1' )); $token = json_decode( $request['body'] ); echo "<pre>"; var_dump($token); echo "</pre>"; إن الخطوة الأولى هو ترميز رمز أمان الوصول والكلمة السرّية بصيغة URL encoding. قمت أيضًا بإضافة ترويستين، واحدة ترويسة استيثاق تحوي على بيانات الوصول. أما الترويسة الثانية فهي ترويسة نوع المحتوى content type، والتي يطلب توثيق تويتر إضافتها. إضافة لما سبق، قمت بملء جسم الطلب تمامًا كما ذكرت الملاحظة السابقة حول grant_type=client_credentials وتم إضافة إصدار HTTP كما يطلب توثيق تويتر أيضًا. سيحتوي الجواب بالإضافة للعديد من المعلومات الأخرى على رمز أمان الوصول في جسم الجواب، وسنحتاج لرمز الأمان هذا في جميع الطلبات اللاحقة المرسلة إلى الواجهة البرمجية الخاصة بتويتر. تخزين رمز أمان الوصول إن رمز الأمان صالح لبعض الوقت، ويعتبر طلبه مجدّدًا هدرًا غير ضروري عند تحميل كل صفحة أو عندما يحتاج تطبيقك أن يقوم بعملية ما وسيؤدي إلى استهلاك عدد الطلبات المسموح بسرعة. يمكن في ووردبريس استخدام عابرة transient لتخزين قيمة رمز الأمان ومن ثم استخدام العابرة عند كل طلب لاحق للواجهة البرمجية. $token = get_transient( 'twitter_access_token' ); $token = ( empty( $token ) ) ? get_twitter_access_token() : $token; $request = wp_remote_get('https://api.twitter.com/1.1/followers/ids.json?screen_name=danielpataki&count=5', array( 'headers' => array( 'Authorization' => 'Bearer ' . $token, 'Content-Type' => 'application/x-www-form-urlencoded;charset=UTF-8' ), 'httpversion' => '1.1' )); $token = json_decode( $request['body'] ); سيؤدي إرسال الطلب السابق إلى واجهة تويتر البرمجية إلى عرض 5 من متابعيّ على تويتر (قائمة بسيطة لأرقام حساباتهم Ids). وكما يظهر في المثال السابق، فإنني أقوم بجلب القيمة التي خزّنتها في العابرة فإن لم تكن موجودة سأقوم باستدعاء التابع get_twitter_access_token() للحصول على رمز أمان جديد ومن ثم إضافته إلى العابرة كي أستخدمه في الطلبات اللاحقة. تجدر الإشارة إلى أن هذه الطريقة تهدف فقط إلى إظهار آلية التنفيذ وليست أفضل طريقة للتنفيذ، وكسيناريو أبسط كنت لأقوم بوضع جميع العبارات الشرطية IFs داخل التابع get_twitter_access_token() الذي سيقوم بتنفيذ جميع الشيفرة السابقة ضمنيًا. التوابع المساعدة في واجهة HTTP البرمجية الآن وبعد أن حصلنا على لمحة جيدة حول هدف المقال، دعونا نلق نظرة على التوابع التي ستساعدك في واجهة HTTP البرمجية في ووردبريس. هناك 4 توابع يمكن بواسطتها تنفيذ طلبات: wp_remote_get() wp_remote_post() wp_remote_head() wp_remote_request() ومن الواضح تمامًا وظيفة كل تابع، أما التابع الأخير wp_remote_request() فهو تابع عام يمكنك استخدامه مع أي طريقة HTTP method. أما التوابع الخمسة التالية فتسمح لك بالحصول على جواب على الطلب بسهولة باستخدام توابع قياسية عوضًا عن الخوض في التعامل مع المصفوفات وعناصرها. wp_remote_retrieve_body() wp_remote_retrieve_header() wp_remote_retrieve_headers() wp_remote_retrieve_response_code() wp_remote_retrieve_response_message() أيضًا يبين اسم كل تابع الهدف الوظيفي له بسهولة، وينصح عند الإمكان باستخدام هذه التوابع عوضًا عن التعامل مع المصفوفات يدويًا، حيث ستسمح هذه الطريقة الموحّدة لمطوّرين آخرين بفهم البرمجية بسهولة واستخدام الخطافات hooks إن أصبحت متاحة في المستقبل. الخلاصة كما ترى فإن التعامل مع واجهة REST البرمجية سهل باستخدام واجهة HTTP البرمجية في ووردبريس وبعض توابع ووردبريس كالعبّارات. أنصح بشدّة تجربة هذا الأمر لأن عملية التطوير في ووردبريس تسير بثقة باتجاه العالم المُقاد باستخدام الواجهات البرمجية وعليك أن تقفز إلى الموكب قبل فوات الأوان. إن كان لديك المزيد من الأسئلة حول استخدام واجهة HTTP البرمجية أو لديك بعض الأفكار حول كيفية استخدامها، فلا تتردد بمناقشة الأمر في قسم التعليقات في الأسفل. ترجمة -وبتصرّف- للمقال How to Use the WordPress HTTP API لصاحبه Daniel Pataki.