هل SQL هو API رفيع المستوى؟

السؤال المزعج

في هندسة البرمجيات الحديثة، كل شيء يمر عبر واجهات برمجة التطبيقات (APIs). REST، GraphQL، gRPC - تتواصل التطبيقات عبر واجهات موثقة ومحددة جيدًا. ولكن هناك API واحد يسبق كل الآخرين، وهو موجود في كل مكان، ولا يسميه أحد حقًا "API": SQL.

SQL هي لغة تعريفية موحدة (ISO/IEC 9075) تتيح لك التفاعل مع البيانات المنظمة. أنت تعلن ما تريد، وليس كيفية الحصول عليه. يعتني محرك قاعدة البيانات بالتنفيذ. إنها، بحكم تعريفها، واجهة برمجة — API.

فلماذا لا يعامل أي شخص SQL مثل API؟

SQL مثل API: الحجج الخاصة بـ

الوصول الموحد للبيانات

يوفر SQL نقطة وصول واحدة إلى البيانات المعقدة. سواء كانت قراءة صف، أو الانضمام إلى عشرة جداول، أو تجميع ملايين الصفوف، أو تعديل البيانات بشكل مجمع، فإن الواجهة هي نفسها: تعليمات SQL المرسلة عبر بروتوكول الشبكة (بروتوكول MariaDB / MySQL، على سبيل المثال).

هذا هو بالضبط ما يفعله API REST: كشف نقطة وصول موحدة للموارد، مع دلالات واضحة (GET = قراءة، POST = إنشاء، وما إلى ذلك). SQL يفعل نفس الشيء مع SELECT، INSERT، UPDATE، DELETE.

التحسين المتكامل

عندما تتصل بـ API REST، فإن رمز الواجهة الخلفية الخاص بك هو الذي يقرر كيفية تنفيذ الاستعلام. عند إرسال استعلام SQL، يختار مُحسِّن قاعدة البيانات أفضل خطة تنفيذ.

يقوم مُحسِّن SQL بتحليل الاستعلام وتقييم إحصائيات الجدول وأخذ الفهارس المتوفرة في الاعتبار وإنشاء خطة تنفيذ مثالية. إنها طبقة من التجريد لا يقدمها سوى عدد قليل من واجهات برمجة التطبيقات: أنت تقول "ماذا"، ويقرر النظام "كيف".

التحكم في الوصول الحبيبي

SQL يدمج نظام التحكم في الوصول الأصلي. يتيح لك المنح والإلغاء التحكم بدقة في من يمكنه فعل ماذا على أي بيانات. وهذا يعادل نظام الترخيص المدمج في API.

GRANT SELECT (product_name, price) ON catalog.products TO 'api_user'@'%';

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

التوحيد القياسي

SQL هو معيار ISO. على الرغم من الاختلافات بين التطبيقات (MariaDB، MySQL، PostgreSQL، Oracle)، فإن جوهر اللغة شائع. يمكن للمطور الذي يعرف SQL التفاعل مع أي قاعدة علائقية.

هذه ميزة لا يتمتع بها سوى عدد قليل من واجهات برمجة التطبيقات. REST ليس معيارًا صارمًا (إنه نمط معماري)، وGraphQL هو معيار أحدث، وgRPC مرتبط بمخازن البروتوكول المؤقتة. SQL لديه أكثر من 40 عامًا من التقييس.

SQL مثل API: الحجج المضادة

الخبرة مطلوبة

SQL قوي ولكنه معقد. كتابة تحديد بسيط يمكن لأي مطور الوصول إليه. تتطلب كتابة استعلام عالي الأداء باستخدام الصلات المعقدة وعناصر CTE المتكررة ووظائف النافذة خبرة كبيرة.

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

الحقن SQL

خطر الحقن SQL هو كعب أخيل SQL-as-API. إذا قام المستهلك ببناء استعلاماته عن طريق تسلسل السلسلة، فستكون البيانات في خطر.

python
# DANGEREUX — injection SQL possible
query = f"SELECT * FROM users WHERE name = '{user_input}'"

# SÉCURISÉ — requête paramétrée
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (user_input,))

لا تواجه واجهات برمجة التطبيقات REST/GraphQL هذه المشكلة الأساسية: يتم فصل الواجهة عن البيانات عن طريق البناء.

لا توجد إدارة الاتصال

لا يدير SQL فكرة جلسة HTTP أو تحديد المعدل أو ترقيم الصفحات الموحد أو إصدار API. يدير البروتوكول MariaDB / MySQL الاتصالات، ولكن لا يوجد ما يعادل رؤوس HTTP أو رموز الحالة 4xx/5xx أو آليات التخزين المؤقت لـ HTTP.

يجب تنفيذ هذه الميزات أعلى SQL، عبر الوكلاء (MaxScale، ProxySQL) أو طبقات التطبيق.

اقتران بالمخطط

يؤدي تعريض SQL إلى ربط المستهلك مباشرة بالمخطط المادي للقاعدة. إذا قمت بإعادة تسمية عمود، أو إضافة جدول، أو تغيير العلاقة، فيجب تحديث جميع استعلامات المستهلك SQL. يقوم API REST أو GraphQL بعزل المستهلك عن هذه التغييرات عبر طبقة التجريد.

الحكم: نعم، ولكن...

SQL هو API عالي المستوى من الناحية الوظيفية. إنه يلبي المعايير الأساسية: واجهة موحدة، الوصول المعلن إلى البيانات، التحسين المتكامل، التحكم في الوصول.

ولكنه API يتطلب خبرة لاستخدامه بشكل صحيح، مما يعرض مخاطر أمنية إذا تم استخدامه بشكل غير صحيح، والذي لا يوفر آليات الإدارة الحديثة (الإصدار، تحديد المعدل، ترقيم الصفحات).

ربما يكون النهج الأفضل هو الهجين:

• SQL كـ API داخلي بين الخدمات الخلفية وقاعدة البيانات، مع طرق العرض والإجراءات المخزنة كطبقة تجريد
• REST/GraphQL كـ API خارجي للمستهلكين الذين لا يحتاجون إلى معرفة الرسم التخطيطي الفعلي

SQL لم يمت. SQL ليست أداة من أدوات الماضي. إنه API - الأقدم والأقوى والأكثر تقديرًا في النظام البيئي للبرمجيات.

تم نشر هذه المقالة في الأصل على متوسط.