إذا تسوقت من واجهة متجر مخصصة لا تبدو كقالب جاهز، فمن المحتمل جدًا أن تكون واجهة برمجة تطبيقات التجارة اللارأسية (headless commerce API) هي التي كانت تقوم بالعمل وراء الكواليس. واجهة برمجة تطبيقات التجارة اللارأسية هي الواجهة التي تكشفها الواجهة الخلفية للتجارة (commerce backend) حتى تتمكن أي واجهة متجر من قراءة المنتجات وبناء سلات التسوق وتقديم الطلبات دون أن تكون مرتبطة بموضوع (theme) مدمج. يشرح هذا المقال ما يعنيه ذلك، وكيف يرتبط بـ التجارة التركيبية و MACH، ولماذا تعتمد فرق واجهة متجرك وشركائك على عقد واجهة برمجة التطبيقات هذا. إنه يبني على فكرة أن البرامج تتجه نحو اللارأسية وواجهة برمجة تطبيقاتك أصبحت الآن هي المنتج.
ماذا تعني "اللارأسية" في التجارة
منصات التجارة التقليدية تُسلم كقطعة واحدة. كتالوج المنتجات، سلة التسوق، عملية الدفع، وصفحات HTML التي تعرضها، جميعها تعيش في نفس النظام. تقوم بتخصيصها وتعديلها ونشرها.
تفصل التجارة اللارأسية ذلك إلى قسمين. تحتفظ الواجهة الخلفية، والتي غالبًا ما تسمى محرك التجارة، بكتالوج المنتجات والتسعير والمخزون وسلة التسوق ومنطق الطلبات. وتصبح الواجهة الأمامية، وهي واجهة متجرك، تطبيقًا منفصلاً تبنيه بالطريقة التي تفضلها. والشيء الوحيد الذي يربطهما هو واجهة برمجة التطبيقات (API).
إذن، "الرأس" هو طبقة العرض التقديمي. تعني اللارأسية إزالة الرأس الثابت وكشف "الجسم"، وهو منطق التجارة، من خلال واجهة برمجة تطبيقات بدلاً من ذلك. يمكن لموقع React أو تطبيق جوال أصلي أو شاشة ثلاجة ذكية أو مساعد صوتي التحدث إلى نفس الواجهة الخلفية لأنهم جميعًا يتحدثون نفس واجهة برمجة التطبيقات.
هذا الفصل هو الهدف الرئيسي. يختار فريق الواجهة الأمامية إطاره الخاص وينشر أعماله وفقًا لجدوله الزمني الخاص. يمتلك فريق الواجهة الخلفية قواعد التجارة. وتكون واجهة برمجة التطبيقات هي الخط الفاصل بينهما.
المقايضة هي أنك تتحمل المزيد من العمل. تمنحك المنصة التقليدية متجرًا يعمل خارج الصندوق. الذهاب إلى اللارأسية يعني أنك تبني وتستضيف واجهة المتجر بنفسك، لذا فإن المرونة تأتي بتكلفة هندسية. تختار الفرق اللارأسية عندما لا يستطيع القالب الجاهز تقديم التجربة التي يحتاجونها، أو عندما يرغبون في خدمة عدة قنوات من واجهة خلفية واحدة.
اللارأسية مقابل التركيبية مقابل MACH
تُستخدم هذه المصطلحات الثلاثة بالتبادل، لكنها تصف نطاقات مختلفة. إليك الشرح الصادق.
| المصطلح | ما يصفه | النطاق |
|---|---|---|
| التجارة اللارأسية (Headless commerce) | فصل الواجهة الأمامية عن واجهة خلفية تجارية واحدة، متصلة عبر واجهة برمجة تطبيقات (API) | واجهة خلفية واحدة، واجهة أمامية واحدة أو عدة واجهات |
| التجارة التركيبية (Composable commerce) | الكومة بأكملها مقسمة إلى خدمات قابلة للتبديل (أفضل ما في فئتها) (كتالوج، بحث، مدفوعات، إدارة معلومات المنتج PIM، نظام إدارة الطلبات OMS) | العديد من الخدمات المستقلة المجمعة معًا |
| MACH | مجموعة من المبادئ المعمارية التي تميل الأكوام التركيبية إلى اتباعها | فلسفة وليست منتجًا |
اللارأسية هي الحالة الضيقة. يمكنك أن تكون لارأسيًا مع واجهة خلفية متجانسة واحدة، طالما أن واجهة المتجر تتحدث إليها عبر واجهة برمجة تطبيقات (API).
تذهب التجارة التركيبية إلى أبعد من ذلك. فبدلاً من واجهة خلفية واحدة، تقوم بتجميع خدمات مستقلة وتختار أفضل أداة لكل وظيفة. بحث من بائع واحد، ومدفوعات من آخر، ومدير معلومات منتج منفصل. كل منها خدمة خاصة بها ولها واجهة برمجة تطبيقات خاصة بها، وتقوم بتركيبها معًا في تجربة واحدة.
MACH هي مجموعة المبادئ التي تقف وراء معظم الحزم التركيبية. وفقًا لتحالف MACH، وهي مجموعة صناعية تشكلت في عام 2020، فإن MACH تعني الخدمات المصغرة (Microservices)، وAPI-first (الواجهة البرمجية أولاً)، وCloud-native SaaS (البرمجيات كخدمة سحابية الأصل)، واللارأسية (Headless). لاحظ أن API-first يقع في المنتصف تمامًا. في عالم MACH، واجهة برمجة التطبيقات ليست ميزة جانبية. إنها الطريقة الوحيدة التي تتحدث بها الأجزاء مع بعضها البعض، وهو نفس المنطق وراء معاملة واجهة برمجة التطبيقات الخاصة بك كمنتج.
ما الذي تكشفه واجهة برمجة تطبيقات التجارة اللارأسية بالفعل
يختلف الشكل الدقيق حسب المنصة، ولكن معظم واجهات برمجة تطبيقات التجارة اللارأسية تغطي نفس الوظائف الأساسية:
- الكتالوج والمنتجات. قراءة المنتجات والمتغيرات والمجموعات والوسائط حتى تتمكن واجهة المتجر من عرض القوائم وصفحات التفاصيل.
- البحث والتصفح. الاستعلام عن الكتالوج وتصفيته وترتيبه.
- سلة التسوق والدفع. إنشاء سلة، إضافة وإزالة عناصر الخط، تطبيق الخصومات، والتحرك نحو الدفع.
- العملاء. تسجيل الدخول، إدارة الحسابات، وتتبع سجل الطلبات.
- المخزون والتسعير. عرض مستويات المخزون والسعر الصحيح للسياق الصحيح.
تقوم بعض المنصات بتقسيم هذه الواجهات إلى واجهة برمجة تطبيقات لمتجر عامة (storefront API) وواجهة برمجة تطبيقات إدارية منفصلة (admin API) لعمل الواجهة الخلفية (back-office). واجهة برمجة تطبيقات المتجر ثقيلة القراءة وموجهة للعملاء. بينما تتولى واجهة برمجة التطبيقات الإدارية تحرير الكتالوج وإدارة الطلبات والتكوين.
البروتوكول مهم أيضًا. العديد من واجهات برمجة تطبيقات التجارة اللارأسية هي GraphQL، مما يتيح لواجهة المتجر طلب الحقول التي تحتاجها بالضبط في دورة واحدة. البعض الآخر يستخدم REST، وبعض المنصات تقدم كلا النوعين. إذا كنت توازن بين المفاضلات، فراجع REST مقابل GraphQL.
المنصات الرئيسية
ينقسم مجال التجارة اللارأسية تقريبًا إلى محركات SaaS ومحركات مفتوحة المصدر. بعض الأسماء التي ستصادفها:
- commercetools. عضو مؤسس في تحالف MACH وواحدة من أكثر منصات التجارة التركيبية المذكورة. مصممة لتكون API-first وسحابية الأصل.
- Shopify. تقدم تصميمات لارأسية من خلال واجهة برمجة تطبيقات المتجر الخاصة بها (Storefront API)، مع Hydrogen كإطار عمل React لاستخدامها. إذا كنت بالفعل في عالم Shopify، فإن برنامجنا التعليمي لواجهة برمجة تطبيقات Shopify هو نقطة بداية جيدة.
- BigCommerce. يدعم الوضع اللارأسي مع واجهات برمجة تطبيقات GraphQL Storefront وCheckout بالإضافة إلى الكتالوج الخاص به. راجع دليلنا حول استخدام واجهات برمجة تطبيقات BigCommerce.
- Saleor. محرك مفتوح المصدر يعتمد على GraphQL أولاً، مبني على Python وDjango.
- Medusa. محرك مفتوح المصدر مبني على Node.js وTypeScript، شائع لدى فرق JavaScript التي ترغب في التحكم الكامل في الواجهة الخلفية.
تحقق من تفاصيل المنصة قبل الالتزام، حيث تتغير الأسعار ونماذج الاستضافة وتغطية واجهة برمجة التطبيقات. النمط عبر جميعها هو نفسه: يقوم المحرك بكشف منطق التجارة من خلال واجهة برمجة تطبيقات، وأنت تبني "الرأس" (الواجهة الأمامية).
لماذا تعتمد الفرق على عقد واجهة برمجة تطبيقات التجارة
بمجرد فصل واجهة المتجر، تتوقف واجهة برمجة التطبيقات عن كونها مجرد سباكة وتصبح الاتفاق الذي يبني عليه الجميع. وهنا تصبح اللارأسية حقيقية.
لا يستطيع فريق الواجهة الأمامية نشر صفحة منتج حتى يعرف الشكل الدقيق لاستجابة المنتج. تتصل جميع تكاملات شركائك، مثل تطبيق الولاء، وخدمة الضرائب، وموجز السوق، بنفس نقاط النهاية. يستهلك فريق الجوال نفس العقد الذي يستهلكه فريق الويب. إذا تغير شكل الاستجابة دون سابق إنذار، يمكن لكل من هؤلاء المستهلكين أن يتعطلوا في وقت واحد.
هذا هو الخطر والفرصة. يتيح عقد واجهة برمجة تطبيقات تجارية واضح ومستقر وموثق جيدًا للفرق المستقلة التحرك بسرعة دون أن تتعارض مع بعضها البعض. بينما يحول العقد الغامض أو المتغير كل إصدار إلى فوضى تنسيقية. العقد هو المنتج، لذا فهو يستحق نفس العناية التي تُمنح لواجهة المتجر نفسها، بما في ذلك اختبار العقد لالتقاط التغييرات التي قد تتسبب في عطل قبل نشرها.
إصدار (Versioning) هو جزء من الصفقة أيضًا. عندما تحتاج إلى تغيير استجابة منتج أو إعادة تسمية حقل، لا يمكنك ببساطة تعديل نقطة النهاية والأمل في الأفضل. المستهلكون الذين لا تتحكم فيهم يقرأونها. لذلك، تتعامل الفرق اللارأسية مع العقد كالتزام عام: تغييرات إضافية حيثما أمكن، ونوافذ واضحة لإلغاء الدعم، واختبارات تحدد أي شيء قد يسبب عطلاً قبل أن يصل إلى تكامل شريك.
أين يتناسب Apidog
لا يقوم Apidog بتشغيل متجرك. إنه ليس محرك تجارة، ولا نظام إدارة محتوى (CMS)، ولا بوابة، ولا يجعل حزمتك لارأسية أو تركيبية. ما يفعله هو امتلاك الركيزة الأساسية لكل هذا وهي "الواجهة البرمجية أولاً": الطبقة التي تصمم فيها وتختبر وتنشئ نماذج وتوثق العقد الذي يعتمد عليه كل شيء آخر.
يتوافق ذلك بشكل واضح مع عمل التجارة اللارأسية:
- صمم العقد أولاً. قم بنمذجة واجهة برمجة تطبيقات المتجر أو المسؤول كـ "مواصفات OpenAPI" في Apidog قبل وجود أي كود، بحيث يتفق فريق الواجهة الأمامية والخلفية على الشكل مسبقًا.
- قم بالمحاكاة قبل أن تكون الواجهة الخلفية جاهزة. قم بتشغيل خادم محاكاة من المواصفات حتى يتمكن فريق واجهة متجرك من البناء بناءً على استجابات منتجات وعربات تسوق واقعية بينما لا يزال محرك التجارة قيد التوصيل. هذا هو الوعد بفك الارتباط الذي أصبح عمليًا، ويمكنك قراءة المزيد في شرح واجهة برمجة التطبيقات الوهمية (mock API) لدينا.
- اختبر العقد في CI (التكامل المستمر). يقوم واجهة سطر الأوامر لـ Apidog بتشغيل اختبارات واجهة برمجة التطبيقات الخاصة بك بدون واجهة رسومية، وهو تنفيذ اختبار لارأسي يتناسب مع مسار العمل. إنه يتناغم مفهوميًا مع التجارة اللارأسية: لا حاجة لواجهة أمامية، فقط يتم التحقق من العقد.
- وثقه للشركاء. توفر المستندات التفاعلية التي تم إنشاؤها تلقائيًا لفرق واجهة متجرك وشركائك مصدرًا واحدًا للحقيقة لواجهة برمجة التطبيقات التي يدمجونها.
لإلقاء نظرة أعمق على سبب أهمية ذلك بمجرد أن تصبح واجهة برمجة التطبيقات هي الواجهة الوحيدة، راجع البرامج تتجه نحو اللارأسية وواجهة برمجة تطبيقاتك أصبحت الآن هي المنتج. إذا كنت ترغب في تجربة سير العمل، قم بتنزيل Apidog واستورد مواصفات موجودة.
أسئلة مكررة
هل التجارة اللارأسية هي نفسها التجارة التركيبية؟
لا. التجارة اللارأسية تفصل واجهة المتجر عن واجهة خلفية تجارية واحدة عبر واجهة برمجة تطبيقات. بينما تذهب التجارة التركيبية أبعد من ذلك وتجمع العديد من الخدمات المستقلة الأفضل في فئتها، كل منها بواجهة برمجة تطبيقات خاصة بها، في تجربة واحدة. كل حزمة تركيبية هي لارأسية، لكن الإعداد اللارأسي بواجهة خلفية متجانسة واحدة ليس بالضرورة تركيبيًا.
هل أحتاج إلى GraphQL لواجهة برمجة تطبيقات التجارة اللارأسية؟
لا. GraphQL شائع لأنه يتيح لواجهة المتجر طلب الحقول التي تحتاجها بالضبط في مكالمة واحدة، وهو ما يناسب عرض المنتجات وعربات التسوق جيدًا. لكن الكثير من واجهات برمجة تطبيقات التجارة اللارأسية تستخدم REST، وبعض المنصات تقدم كلاهما. البروتوكول أقل أهمية من استقرار العقد وتوثيقه.
هل يمكنني اختبار واجهة برمجة تطبيقات التجارة اللارأسية قبل بناء الواجهة الخلفية؟
نعم، وهذا أحد الأسباب الرئيسية للبدء بالتصميم أولاً. إذا قمت بنمذجة عقد واجهة برمجة التطبيقات كمواصفات، يمكنك إنشاء خادم وهمي يعيد استجابات واقعية. يقوم فريق واجهة متجرك بالبناء والاختبار مقابل هذا الخادم الوهمي بينما لا يزال محرك التجارة قيد التطوير، ثم ينتقلون إلى نقاط النهاية الحقيقية لاحقًا.
ما هو تحالف MACH؟
تحالف MACH هو مجموعة صناعية تشكلت في عام 2020 لتعزيز حزم التقنيات المفتوحة والأفضل في فئتها والمبنية على مبادئ الخدمات المصغرة (Microservices)، الواجهة البرمجية أولاً (API-first)، البرمجيات كخدمة سحابية الأصل (Cloud-native SaaS)، واللارأسية (Headless). البائعون مثل commercetools هم أعضاء مؤسسون. MACH هي مجموعة من المبادئ المعمارية، وليست منتجًا واحدًا تشتريه.
العقد هو المتجر
تنقل التجارة اللارأسية القيمة من القالب إلى واجهة برمجة التطبيقات. بمجرد فصل واجهة المتجر، تصبح واجهة برمجة تطبيقات التجارة هي ما يعتمد عليه فرق الواجهة الأمامية والجوال والشركاء في البناء. وتدفع التجارة التركيبية و MACH هذا أبعد من خلال جعل "API-first" مبدأً أساسيًا بدلاً من كونه ميزة إضافية.
لا يعتمد أي من ذلك على Apidog، ولكن جودة العقد تستفيد من مكان لتصميمه ومحاكاته واختباره وتوثيقه. إذا كان مشروعك اللارأسي يتجه في هذا الاتجاه، فإن Apidog يوفر لك هذه الطبقة دون التظاهر بأنه محرك التجارة الأساسي.