0Pricing
AI SaaS Builder · درس

تصميم RESTful APIs

أنشئ APIs منظّمة وفعّالة للتواصل السلس بين الواجهة الأمامية والواجهة الخلفية

تصميم RESTful APIs درس مجاني في AI SaaS Builder على CoddyKit. هذا هو الدرس 1 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في AI SaaS Builder، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة AI SaaS Builder 4 دروس في المجموع.

واجهات API: حلقة وصل الاتصال بتطبيقكم

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

تشبه واجهة API (واجهة برمجة التطبيقات) قائمة الطعام في المطعم. فهي تعرض الأطباق (الدوال) التي يمكنكم طلبها، وتوضح المكونات (المعلمات) التي يجب تقديمها، وما ستحصلون عليه في المقابل (النتائج).

بالنسبة إلى تطبيقات الويب، تُعد واجهات RESTful API الطريقة الأكثر شيوعًا لتواصل أنظمة الواجهة الأمامية والخلفية عبر الإنترنت.

ما المقصود بـ REST؟

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

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

  • قابلة للتوسع: يمكنها التعامل مع عدد أكبر من الطلبات.
  • مرنة: يسهل تطويرها وتكييفها.
  • سهلة الصيانة: أبسط في الفهم والإصلاح.

تتمثل الفكرة الأساسية في التعامل مع كل شيء باعتباره «موردًا».

المبادئ الأساسية لـ REST

يعتمد REST على عدة مبادئ أساسية لتحقيق مزاياه:

  • العميل والخادم: فصل المسؤوليات؛ يتولى العميل واجهة المستخدم، بينما يتولى الخادم تخزين البيانات ومعالجتها.
  • عديم الحالة: يجب أن يحتوي كل طلب من العميل إلى الخادم على جميع المعلومات اللازمة لفهم الطلب. ولا يخزّن الخادم أي سياق للعميل بين الطلبات.
  • قابل للتخزين المؤقت: يمكن وضع علامة على الاستجابات باعتبارها قابلة للتخزين المؤقت لتحسين الأداء.
  • واجهة موحّدة: يُعد هذا المبدأ الأهم في التصميم؛ إذ يبسط النظام من خلال توفير طريقة متسقة للتفاعل مع الموارد.

الموارد: الأسماء في واجهة API الخاصة بكم

يعني مبدأ «الواجهة الموحّدة» أن تركز واجهة API الخاصة بكم على الموارد. والمورد هو أي معلومة يمكن تسميتها، مثل مستخدم أو منتج أو طلب.

عند التصميم، تعاملوا مع الموارد باعتبارها أسماء لا أفعالًا. ويجب أن تعكس نقاط نهاية API الخاصة بكم (عناوين URL) هذه الأسماء، وعادةً بصيغة الجمع.

  • بدلًا من /getUser، استخدموا /users
  • بدلًا من /createProduct، استخدموا /products
  • بدلًا من /deleteOrder/123، استخدموا /orders/123

يجعل ذلك واجهة API الخاصة بكم بديهية ومتسقة.

طرق HTTP: الإجراءات

بعد تحديد الموارد (مثل /products)، تستخدمون طرق HTTP القياسية لتنفيذ الإجراءات عليها. وتشبه هذه الطرق الأفعال المرتبطة بأسمائكم.

  • GET: استرداد البيانات. (مثلًا، GET /products للحصول على جميع المنتجات)
  • POST: إنشاء بيانات جديدة. (مثلًا، POST /products لإضافة منتج جديد)
  • PUT: تحديث البيانات الموجودة أو استبدالها. (مثلًا، PUT /products/123 لتحديث المنتج 123)
  • DELETE: إزالة البيانات. (مثلًا، DELETE /products/123 لإزالة المنتج 123)

توجد أيضًا PATCH لإجراء تحديثات جزئية، لكن هذه الطرق الأربع هي الأكثر أساسية.

مثال: استرداد البيانات (GET)

لنرَ كيف يتفاعل العميل مع واجهة RESTful API لاسترداد البيانات باستخدام طريقة GET.

نسترد هنا منشورًا محددًا من واجهة API عامة للاختبار. ويحدد عنوان URL /posts/1 المورد بوضوح.

import requests

# Define the API endpoint for a specific post
url = "https://jsonplaceholder.typicode.com/posts/1"

# Send a GET request
response = requests.get(url)

# Check if the request was successful (status code 200)
if response.status_code == 200:
  print("Successfully retrieved data:")
  print(response.json())
else:
  print(f"Error: {response.status_code} - {response.text}")

مثال: إنشاء البيانات (POST)

لإنشاء مورد جديد، نستخدم طريقة POST. وتُرسل البيانات الجديدة في نص الطلب، وعادةً بتنسيق JSON.

لاحظوا أننا نرسل الطلب إلى نقطة نهاية المورد بصيغة الجمع (/posts) من دون معرّف، لأن الخادم سيعيّن معرّفًا للمورد.

import requests
import json

# Define the API endpoint for creating posts
url = "https://jsonplaceholder.typicode.com/posts"

# Define the data for the new post
new_post_data = {
  "title": "CoddyKit Lesson",
  "body": "This is a new post from CoddyKit!",
  "userId": 1
}

# Send a POST request with the JSON data
response = requests.post(url, json=new_post_data)

# Check if the request was successful (status code 201 Created)
if response.status_code == 201:
  print("Successfully created post:")
  print(response.json())
else:
  print(f"Error: {response.status_code} - {response.text}")

رموز حالة HTTP: استجابة واجهة API

بعد كل طلب، ترسل واجهة API رمز حالة HTTP. ويخبر هذا الرقم المكوّن من ثلاثة أرقام العميل بما إذا كان الطلب ناجحًا، وما إذا كان قد حدث خطأ، ونوعه.

  • 2xx نجاح: 200 OK (نجاح عام)، 201 Created (تم إنشاء المورد)، 204 No Content (نجاح، ولكن لا توجد بيانات لإرجاعها).
  • 4xx خطأ من العميل: 400 Bad Request (طلب غير صالح)، 401 Unauthorized (بيانات المصادقة مفقودة)، 403 Forbidden (تمت المصادقة، ولكن لا يوجد إذن بالوصول)، 404 Not Found (المورد غير موجود).
  • 5xx خطأ من الخادم: 500 Internal Server Error (حدث خطأ ما على الخادم).

يُعد استخدام رموز الحالة المناسبة أمرًا بالغ الأهمية لتصميم واجهة API جيدة.

تنسيق البيانات: JSON للبساطة

عند إرسال البيانات إلى واجهة RESTful API ومنها، يُستخدم JSON (JavaScript Object Notation) عادةً كتنسيق شائع.

يتميز JSON بخفته وسهولة قراءته من قِبل البشر وسهولة تحليله باستخدام معظم لغات البرمجة. ويمثل البيانات في صورة أزواج مفتاح-قيمة ومصفوفات، مما يجعله مثاليًا للمعلومات المنظمة.

رغم أن XML كان شائعًا في السابق، أصبح JSON المعيار الفعلي لواجهات API على الويب بفضل بساطته وكفاءته.

إصدار واجهة API الخاصة بكم

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

يتيح لكم الإصدار إجراء تغييرات من دون تعطيل التطبيقات الحالية التي تعتمد على واجهة API الخاصة بكم. ومن الأساليب الشائعة تضمين رقم الإصدار في عنوان URL:

  • /v1/users (للإصدار 1)
  • /v2/users (للإصدار 2)

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

اختبروا مهاراتكم في تصميم واجهات API

أيّ مما يلي يُعد من المبادئ الأساسية لتصميم واجهات RESTful API؟

مراجعة: تصميم واجهات API قوية

تهانينا! لقد تعلمتم أساسيات تصميم واجهات RESTful API.

  • تتيح واجهات API الاتصال بين الواجهة الأمامية والواجهة الخلفية.
  • REST هو نمط معماري يركز على الموارد وطرق HTTP القياسية.
  • يجب تعريف الموارد باستخدام أسماء بصيغة الجمع في عناوين URL الخاصة بكم.
  • تحدد طرق HTTP (GET وPOST وPUT وDELETE) الإجراءات المنفذة على هذه الموارد.
  • توفر رموز حالة HTTP معلومات مهمة عن نتائج الطلبات.
  • يُعد JSON تنسيق البيانات المفضل للتواصل عبر واجهات API.
  • يضمن إصدار واجهة API تطورها بسلاسة وتوافقها مع الإصدارات السابقة.

يُعد إتقان هذه المفاهيم أساسيًا لبناء واجهات خلفية لـ AI SaaS قابلة للتوسع وسهلة الصيانة.

الأسئلة الشائعة

هل درس «تصميم RESTful APIs» مجاني؟

نعم — نص درس «تصميم RESTful APIs» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة AI SaaS Builder، انتقل إلى CoddyKit PRO. تتضمن دورة AI SaaS Builder 4 دروس في المجموع.

ماذا ستتعلم في «تصميم RESTful APIs»؟

أنشئ APIs منظّمة وفعّالة للتواصل السلس بين الواجهة الأمامية والواجهة الخلفية تتمرن على AI SaaS Builder مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ AI SaaS Builder؟

لا تُشترط خبرة سابقة. AI SaaS Builder على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 1 من أصل 4.

كم من الوقت يستغرق درس «تصميم RESTful APIs»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس AI SaaS Builder هذا؟

نعم. كل درس في AI SaaS Builder يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. تصميم RESTful APIs
  2. إدارة قواعد البيانات لـ SaaS
  3. مصادقة المستخدم وتفويضه
  4. تحديد معدل الطلبات ووضع طلبات الذكاء الاصطناعي في قوائم انتظار
← العودة إلى AI SaaS Builder