نظرًا لكونها القنوات التي تتفاعل من خلالها عناصر البرامج وتتدفق من خلالها البيانات عبر الإنترنت، فإن واجهات برمجة التطبيقات (APIs) هي شريان الحياة لخدمات الويب المعاصرة. تعمل تقنيات واجهة برمجة التطبيقات مثل SOAP (بروتوكول مراسلة خدمات الويب) وREST (النمط المعماري) وGraphQL(لغة البرمجة وأداتها) على تبسيط عملية تطوير البرامج من خلال تفعيل التكامل بين بيانات الجهات الخارجية وخدماتها. كما تمكّن واجهات برمجة التطبيقات (APIs) الشركات من تقديم وظائف خدمة آمنة وتبادل البيانات بين الموظفين وشركاء الأعمال والمستخدمين.
على الرغم من تعدد أنواع واجهات برمجة التطبيقات، فإن النقاشات التي تدور حول نموذجين رئيسيين قد هيمنت على المحادثات في السنوات الأخير، وهما: REST (نقل الحالة التمثيلية) وGraphQL. وكلاهما يقدم مجموعة من الميزات، ولذا يُستخدمان في مشروعات الشبكات حول العالم. ولكنهما يختلفان كثيرًا في كيفية إدارتهما لحركة البيانات. وهنا، نحلل هذه الاختلافات ونناقش كيف يمكن للشركات استخدام واجهتَي برمجة التطبيقات REST وGraphQL لتحسين شبكاتها.
يعد فهم واجهات برمجة تطبيقات REST و GraphQL بشكل فردي ضروريًا للمقارنة بين الاثنين.
تُعد تقنية REST، المطورة في مطلع العقد الأول من القرن الحادي والعشرين، نمطًا معماريًا منظمًا لتطبيقات الوسائط المتعددة المتصلة بالشبكة، وهي مصممة للعمل ببروتوكول اتصال عديم الحالة بين العميل والخادم قابل للتخزين المؤقت. واجهات برمجة تطبيقات REST، يطلق عليها أيضًا اسم RESTful APIs، هي برامج تشغيل لبنى REST.
تستخدم واجهات برمجة تطبيقات REST معرّفات الموارد الموحدة (URIs) لمعالجة الموارد. وتعمل واجهات برمجة تطبيقات REST من خلال وجود نقاط نهاية مختلفة تقوم بتنفيذ عمليات CRUD ("إنشاء" و"قراءة" و"تحديث" و"حذف") لموارد الشبكة. وهي تعتمد على تنسيق بيانات محدد مسبقًا—يسمى نوع الوسائط أو نوع MIME—لتحديد شكل الموارد التي يقدمونها للعملاء وحجمها. التنسيقان الأكثر شيوعًا هما JSON وXML (وأحيانًا HTML أو النص العادي).
عندما يطلب العميل موردًا من الموارد، يعالج الخادم طلب الاستعلام ويعيد كل البيانات المتعلقة بهذا المورد. تتضمن الاستجابة رموز استجابة HTTP مثل "200 OK" (لطلبات REST الناجحة) و"404 Not Found" (للموارد غير الموجودة).
إن GraphQL هي لغة استعلام ووقت تشغيل واجهة برمجة تطبيقات (API) طورتها فيسبوك داخليًا في عام 2012 قبل أن تصبح مصدرًا مفتوحًا في عام 2015.
يُعرَّف GraphQL بواسطة مخطط واجهة برمجة تطبيقات مكتوب بلغة تعريف مخطط GraphQL. ويحدد كل مخطط أنواع البيانات التي يُمكن للمستخدم الاستعلام عنها أو تعديلها، والعلاقات بين الأنواع. ويدعم مُحلِّل كل حقل في مخطط. ويوفر المُحلِّل تعليمات لتحويل استعلامات GraphQL والتغيرات والاشتراكات إلى بيانات، ويسترجع البيانات من قواعد البيانات والخدمات السحابية ومصادر أخرى. كما توفر المُحلِّلات مواصفات تنسيق البيانات وتمكّن النظام من تجميع البيانات من مصادر مختلفة.
على عكس تقنية REST، التي تستخدم عادةً نقاط نهاية متعددة لجلب البيانات وتنفيذ عمليات الشبكة، تعرض تقنية GraphQL نماذج البيانات باستخدام نقطة نهاية واحدة يرسل العملاء من خلالها طلبات GraphQL، بغض النظر عما يطلبونه. تصل واجهة برمجة التطبيق بعد ذلك إلى خصائص الموارد—وتتبع المراجع بين الموارد—لتقديم جميع البيانات التي يحتاجها العميل من خلال طلب استعلام واحد مرسل إلى خادم GraphQL.
إن كلًا من GraphQL وREST APIs هما تبادلات بيانات قائمة على الموارد تستخدم طرق HTTP (مثل طلبات PUT وGET) التي تُحدد العمليات التي يمكن للعميل تنفيذها. ومع ذلك، هناك اختلافات رئيسية بينهما لا تُفسر انتشار GraphQL فحسب، بل تفسر كذلك سبب بقاء أنظمة RESTful لفترة طويلة.
توفر GraphQL إضافة فعّالة وأكثر مرونة إلى REST؛ وغالبًا ما يُنظر إلى واجهات برمجة تطبيقات GraphQL على أنها ترقية من بيئات RESTful، نظرًا إلى قدرتها على تسهيل التعاون بين فرق الواجهة الأمامية والخلفية على وجه الخصوص. وتوفر GraphQL خطوة منطقية تالية في رحلة واجهة برمجة تطبيقات المؤسسة، ما يساعد على حل المشكلات التي تواجهها غالبًا مع REST.
ومع ذلك، كانت REST لفترة طويلة المعيار لبُنى واجهة برمجة التطبيقات، ولا يزال العديد من المطورين والمهندسين المعماريين يعتمدون على تكوينات RESTful لإدارة شبكات تقنية المعلومات. وعلى هذا النحو، فإن فهم الفروق بين الاثنين أمر أساسي لأي استراتيجية لإدارة تقنية المعلومات في المؤسسة.
تختلف واجهات برمجة التطبيقات REST وGraphQL في كيفية إدارتها:
نظرًا إلى أن REST تعتمد على نقاط نهاية متعددة وتفاعلات عديمة الحالة—حيث تتم معالجة كل طلب من واجهة برمجة التطبيقات كاستعلام جديد، مستقل عن أي طلبات أخرى—يتلقى العملاء كل جزء من البيانات المرتبطة بالمَورد. وإذا كان العميل بحاجة إلى مجموعة فرعية من البيانات فقط، فإنه لا يزال يتلقى جميع البيانات (الجلب الزائد). وإذا كان العميل بحاجة إلى بيانات تمتد على عدة موارد، فإن نظام RESTful غالبًا ما يجعل العميل يستعلم عن كل مورد على حدة لتعويض عدم كفاية استرجاع البيانات من الطلب الأولي (جلب أقل من المطلوب). تستخدم واجهات برمجة التطبيقات GraphQL نقطة نهاية GraphQL واحدة لمنح العملاء استجابة دقيقة وشاملة للبيانات في رحلة واحدة من طلب واحد، ما يقضي على مشكلات الجلب الأكثر أو الأقل من المطلوب.
في بنية تقنية REST، يجب على الفرق إصدار واجهات برمجة التطبيقات لتعديل تراكيب البيانات، وتجنب وقوع أخطاء النظام وانقطاع الخدمة لدى المستخدم النهائي. بمعنى آخر، يجب على المطورين إنشاء نقطة نهاية جديدة في كل مرة يجرون فيها تغييرات، ما يؤدي إلى إنشاء إصدارات متعددة من واجهة برمجة التطبيقات وربما تتعقد عملية الصيانة. تقلل تقنية GraphQL من الحاجة إلى تعيين الإصدار لأنه يمكن للعملاء تحديد متطلبات البيانات الخاصة بهم في الاستعلام. لا تؤثر إضافة حقول جديدة إلى الخادم في العملاء الذين لا يحتاجون إلى تلك الحقول. وفي المقابل، إذا أُهملت الحقول، فقد يستمر العملاء في طلبها حتى يتم تحديث الاستعلامات.
يجب أن تستخدم واجهات برمجة التطبيقات REST رموز حالة HTTP للإشارة إلى حالة الطلب أو نجاحه، ولكل رمز حالة معنى محدد. ويُرجع طلب HTTP الناجح رمز الحالة 200، بينما قد يُرجع خطأ العميل رمز الحالة 400 وقد يُرجع خطأ الخادم رمز الحالة 500.
للوهلة الأولى، يبدو هذا النهج في الإبلاغ عن الحالة أكثر وضوحًا، ولكن غالبًا ما تكون رموز حالة HTTP أكثر فائدة لمستخدمي الويب من واجهات برمجة التطبيقات نفسها، خاصةً في حالة وجود أخطاء. لا تحتوي REST على مواصفات للأخطاء، لذلك يمكن أن تظهر أخطاء واجهة برمجة التطبيقات كأخطاء نقل أو لا تظهر مع رمز الحالة على الإطلاق. يمكن أن تجبر هذه الديناميكية الموظفين على قراءة وثائق الحالة لفهم ما تعنيه الأخطاء أو حتى كيفية الإبلاغ عن الأخطاء داخل البنية التحتية.
باستخدام واجهات برمجة التطبيقات GraphQL، فإن كل طلب—بغض النظر عما إذا كان قد نتج عنه خطأ—يُرجع رمز حالة OK 200 لأنه لا يتم الإبلاغ عن وجود الأخطاء باستخدام رموز حالة HTTP (باستثناء أخطاء النقل). وبدلًا من ذلك، يُبلغ النظام عن الأخطاء في نص الاستجابة مع البيانات، لذا على العملاء تحليل حمولة البيانات لتحديد ما إذا كان الطلب ناجحًا أم لا.
ومع ذلك، فإن تقنية GraphQL لديها مواصفات للأخطاء، لذلك يمكن تمييز أخطاء واجهة برمجة التطبيقات عن أخطاء النقل بسهولة. تظهر طبيعة الأخطاء الحقيقية في وحدة إدخال "الأخطاء" في نص الاستجابة، ما قد يجعل واجهات برمجة تطبيقات GraphQL لها الأفضلية عليها في التصميم.
لا تحتوي REST على دعم مضمّن للتحديثات في الوقت الفعلي. وإذا كان التطبيق يحتاج إلى وظيفة في الوقت الفعلي، فعادةً على المطورين تنفيذ تقنيات مثل الاستطلاع الطويل (حيث يستطلع العميل الخادم بشكل متكرر للحصول على بيانات جديدة) والأحداث المرسلة من الخادم، ما قد يضيف تعقيدًا إلى التطبيق.
ومع ذلك، تتضمن GraphQL دعمًا مضمّنًا للتحديثات في الوقت الفعلي من خلال الاشتراكات. وتحافظ الاشتراكات على اتصال ثابت بالخادم، ما يتيح للخادم إرسال التحديثات إلى العميل كلما وقعت أحداث محددة.
بيئة تقنية REST مصممة ببراعة، بفضل وجود مجموعة واسعة من الأدوات والمكتبات وأطر العمل المتاحة للمطورين. ومع ذلك، يتطلب العمل مع واجهات برمجة تطبيقات REST من الفرق التنقل بين العديد من نقاط النهاية وفهم الاتفاقيات والأنماط الموحدة لكل واجهة برمجة تطبيق.
إن واجهات برمجة التطبيقات GraphQL جديدة نسبيًا، ولكن بيئة GraphQL نمت كثيرًا منذ طرحها، مع توفر العديد من الأدوات والمكتبات المختلفة لتطوير كل من الخادم والعميل. وتوفر أدوات مثل GraphiQL وGraphQL Playground بيئات تطوير متكاملة (IDEs) قوية داخل المتصفح لاستكشاف واجهات برمجة تطبيقات GraphQL واختبارها. إضافة إلى ذلك، يتمتع GraphQL بدعم قوي لإنشاء التعليمات البرمجية، ما يمكن أن يبسط عملية التطوير من جانب العميل.
تعتمد واجهات برمجة التطبيقات REST على آليات مثل رؤوس علامات eTags وتاريخ التعديل الأخير لتخزين مكالمات واجهة برمجة التطبيقات مؤقتًا. ورُغم فعالية استراتيجيات التخزين المؤقت هذه، فإنها قد تكون معقدة في التنفيذ وقد لا تكون مناسبة لجميع حالات الاستخدام.
قد تكون واجهات برمجة تطبيقات GraphQL أكثر صعوبة في التخزين المؤقت بسبب الطبيعة الديناميكية للاستعلامات. ومع ذلك، يُمكن أن يخفف نشر الاستعلامات المستمرة، والتخزين المؤقت للاستجابات، والتخزين المؤقت من جانب الخادم من هذه الصعوبات ويبسّط جهود التخزين المؤقت الأوسع في بُنى GraphQL.
ليس لواجهات برمجة تطبيقات REST أ وGraphQL ميزة على الأخرى بطبيعتها؛ فهي أدوات مختلفة تناسب مهامًا مختلفة.
تعتبر REST أسهل تنفيذًا بشكل عام ويمكن أن تكون خيارًا جيدًا عندما يكون بروتوكول الاتصال المباشر والقابل للتخزين المؤقت مع ضوابط وصول صارمة هو الخيار المفضل (لمواقع التجارة الإلكترونية التي تواجه الجمهور مثل Shopify و GitHub، كمثال واحد). ونظراً لمخاطر الجلب الناقص والمفرط للبيانات، فإن واجهات برمجة التطبيقات REST هي الأفضل من أجل:
تتيح واجهات برمجة التطبيقات GraphQL إمكانية جلب البيانات على نحوٍ أكثر مرونة وكفاءة، ما يُمكن أن يُحسِّن أداء النظام وسهولة الاستخدام للمطورين. وتجعل هذه الميزات GraphQL مفيدة بشكل خاص لبناء واجهات برمجة التطبيقات في البيئات المعقدة ذات متطلبات الواجهة الأمامية سريعة التغير. وهذا يشمل:
على الرغم من أنهما يستخدمان أساليب مختلفة، فإن كلاً من واجهات برمجة تطبيقات GraphQL وREST لديهما القدرة على تحسين قابلية توسيع الشبكة ومستوى أداء الخادم بشكل كبير.
بغض النظر عما إذا كنت تختار نشر واجهات برمجة التطبيقات REST أو GraphQL—أو مزيجًا من الاثنين—يُمكن أن تستفيد شركتك من مجموعة واسعة من التطبيقات المحتملة، مثل عمليات التنفيذ بلغات البرمجة المختلفة (مثل JavaScript) والتكامل مع الخدمات المصغرة والبُنى من دون خادم. وبفضل IBM API Connect، يُمكنك استخدام كلا النوعين من واجهة برمجة التطبيقات لتحسين البنية التحتية لتقنية المعلومات لديك.
IBM API Connect هو حل لإدارة دورة حياة واجهة برمجة تطبيقات كاملة يساعدك على إنشاء واجهات برمجة التطبيقات وإدارتها وتأمينها وإضفاء الطابع الاجتماعي عليها وتحقيق الدخل منها، وتعزيز التحول الرقمي عبر مراكز البيانات والبيئات السحابية. هذا يعني أن كلاً من الشركات والعملاء يمكنهم تشغيل التطبيقات الرقمية وتحفيز الابتكار في الوقت الفعلي.
وبفضل API Connect، يُمكن للمؤسسات ضمان ريادتها في مجال إدارة واجهات برمجة التطبيقات، الأمر الذي سيكون له قيمة لا تُقدَّر في بيئة الحوسبة المتنامية في الحجم والتعقيد والتنافسية بمرور الوقت.