انتهت الوحدة الأولى بإنشاء طلب HTTP وإرساله والحصول على رد.

سنفعل هذا عدة مرات في المستقبل. سنرسل الطلبات إلى خوادم الطرف الثالث. سنقوم بتقديم الطلبات التي تقبل هذه الطلبات بنفسها ونرد عليها بالرد. سنقوم بإنشاء منطق معقد لمعالجة الطلبات.

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

هذا ما سنفعله في الوحدة الثانية. لنذهب!

لنبدأ بالنظرية.


تعلم REST API

أساسيات REST API

إذا كنت قد أنجزت واجبك في الوحدة الأولى ودرست التوثيق ، فلا بد أنك لاحظت اختصار API. في الواقع ، فإن وثائق واجهة برمجة التطبيقات هي أول شيء يجب على المطورين دراسته إذا كانوا يريدون فهم التفاعل مع بعض الخدمات أو التطبيقات على الشبكة.

API - واجهة برمجة التطبيقات. هذا وصف للطرق التي يمكن للعميل والخادم من خلالها التواصل مع بعضهما البعض. نفتح وثائق API ونتعلم من هناك كيفية الحصول على البيانات اللازمة من الخادم.

نريد دائمًا أن يكون هذا التفاعل بسيطًا ومفهومًا. هذا يبسط المهمة لكل من المطورين (لا حاجة لإعادة اختراع العجلة عند تصميم خدمة جديدة) والمستخدمين (الخدمة أسهل بكثير لمعرفة ما إذا كانت تعمل على نفس مبدأ الخدمات المألوفة سابقًا). وهنا يجدر تذكر مصطلح جديد - REST.

REST - اختصار لنقل الدولة التمثيلية . قد لا يبدو الأمر واضحًا للغاية ، ولكن ببساطة ، REST هو أسلوب التفاعل (تبادل المعلومات) بين العميل والخادم.

هذه ليست مجموعة صارمة من القواعد والمتطلبات. لا تفرض REST استخدام أي لغة برمجة معينة ، ولا تلزم الأيدي بإرشادات صارمة. يُطلق على REST نمطًا معماريًا ويحدد 6 مبادئ يجب أن تمتثل لها بنية النظام.

وفقًا لذلك ، يُطلق على واجهة برمجة التطبيقات التي تم تطويرها مع مراعاة مبادئ REST اسم REST API ، وتسمى التطبيقات نفسها RESTful

سنقوم بإنشاء تطبيقات RESTful فقط ، لذلك يجدر مناقشة المبادئ التي سيلتزمون بها على الفور.

  1. نموذج خادم العميل. يحدد المبدأ الفصل بين العميل والخادم ، والتمايز بين احتياجاتهم. لا داعي للقلق على العميل بشأن كيفية تخزين البيانات ، فالشيء الرئيسي هو أن يتم إصدارها عند الطلب. في المقابل ، لا يهتم الخادم بما سيفعله العميل بهذه البيانات ، وكيفية معالجتها وعرضها بشكل أكبر. هذا يسمح لهم بالتطوير بشكل مستقل عن بعضهم البعض ، ويحسن قابلية تطوير النظام.
  2. انعدام الجنسية. يعني هذا المبدأ أن الخادم يجب ألا "يفكر" في الاستجابة بناءً على الخبرة السابقة مع هذا العميل. يتم تقديم أي طلب بطريقة تحتوي على جميع المعلومات اللازمة لمعالجته ، بغض النظر عن الطلبات السابقة.
  3. التخزين المؤقت. لتقليل البيانات المرسلة ، توجد آلية للتخزين المؤقت. على سبيل المثال ، إذا تم عرض شعار في إحدى الصفحات ، فلا معنى لطلبه من الخادم في كل مرة. لا يتغير كثيرًا ، يكفي الحصول عليه مرة واحدة وحفظه على كمبيوتر العميل ، في ذاكرة التخزين المؤقت. ولكن إذا احتجنا إلى الحصول على معلومات حول السرعة الحالية للسيارة ، فلن تساعد ذاكرة التخزين المؤقت بأي شكل من الأشكال. يحدد هذا المبدأ أن البيانات المرسلة من قبل الخادم يجب تعيينها على أنها قابلة للتخزين المؤقت أم لا.
  4. واجهة موحدة. يحدد المبدأ تنسيقًا واحدًا للتفاعل بين العميل والخادم. يجب أن تكون بنية جميع الطلبات متطابقة. يجب إرسال البيانات بنفس النموذج بغض النظر عمن يطلبها.
  5. نظام الطبقات. لا يتواصل العميل والخادم بالضرورة بشكل مباشر. يمكن أن يمر نقل البيانات عبر عدة عقد وسيطة. في هذه الحالة ، تم تصميم النظام بحيث لا يعرف العميل ولا الخادم ما إذا كان يتفاعل مع التطبيق النهائي أو عقدة وسيطة. هذا يسمح لك بموازنة الحمل على الخوادم ، وزيادة قابلية التوسع.
  6. كود عند الطلب (اختياري) . المبدأ الوحيد الذي ليس إلزاميا. وفقًا لذلك ، يمكن للعميل توسيع وظائفه عن طريق تنزيل رمز قابل للتنفيذ من الخادم (على سبيل المثال ، البرامج النصية). في هذه الحالة ، يجب تنفيذ الكود عند الطلب فقط.

ليس الكثير من النظرية؟

دعونا نضع هذا موضع التنفيذ.

إنشاء طلب API

لنفتح AppMaster ، وننشئ طلب API باستخدامه ، ونفهم بشكل أفضل كيفية عمل هذا الطلب.


يتم إنشاء طلبات واجهة برمجة التطبيقات في قسم "منطق العمل" ، في علامة التبويب "طلبات واجهة برمجة التطبيقات الخارجية".

حان الوقت للنقر على "+ طلب واجهة برمجة تطبيقات جديد".


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

دعونا نتعامل مع البيانات المهمة حقًا.

الحد الأدنى المطلوب لإنشاء طلب هو تحديد أسلوبه وعنوانه (URL). لنبدأ بالآخر.


URL - محدد موقع المعلومات. عنوان معين لمورد معين على الإنترنت. النسخة الأكثر شيوعًا من هذا المورد هي صفحة HTML - ندخل عنوان URL الخاص بها في شريط عنوان المتصفح ونفتح الموقع المطلوب. في الوقت نفسه ، يمكن أن يكون المورد نفسه أي شيء ، صورة ، مقطع فيديو ، مجموعة بيانات. الشيء الرئيسي هو أن هذا المورد يحتوي على مؤشر محدد - عنوان URL يمكنك إرسال طلب إليه للحصول على هذا المورد.

بالإشارة إلى البيانات الموجودة في عنوانها ، نشير أيضًا إلى الطريقة (يمكنك أيضًا تحديد نوع) الطلب ، أي أننا نشير إلى ما يجب فعله بالفعل بهذه البيانات.

عندما أرسلنا طلبات لمهمة الوحدة الأولى ، تلقينا البيانات. هذه هي طريقة GET. هذه الطريقة هي الطريقة الأكثر وضوحًا وهي أيضًا الطريقة الوحيدة المطلوبة. لذلك ، حتى لو لم نحددها صراحةً ، فلا يزال من المفترض افتراضيًا أن هذا هو GET.

دعونا نرى ما هي الطرق الأخرى الموجودة.


لا يحد معيار HTTP نفسه من عدد الطرق التي يمكن استخدامها. في الوقت نفسه ، لا يزال يتم استخدام بعض الأساليب القياسية فقط للحفاظ على التوافق. هناك 5 طرق مختلفة يمكن استخدامها في طلبات AppMaster API.

  • احصل عليه . لقد تم التعامل معها بالفعل. تطلب الطريقة توفير مورد ، وتتلقى البيانات.
  • نشر . لأخذ البيانات من مكان ما ، عليك أولاً وضع هذه البيانات هناك. طريقة POST تفعل ذلك بالضبط. يرسل البيانات إلى الخادم ، وإنشاء مورد.
  • ضع . تشبه طريقة POST ، لكن وظيفتها هي تحديث البيانات. لا يُنشئ بيانات جديدة ، لكنه يستبدل البيانات الموجودة ويحدّثها.
  • حذف . كما يوحي الاسم ، فإنه يحذف البيانات.
  • رقعة . تشبه هذه الطريقة طريقة PUT ، ولكنها تُستخدم لتحديث البيانات جزئيًا ، بدلاً من استبدالها بالكامل. على سبيل المثال ، باستخدام طريقة التصحيح ، يمكنك تغيير عنوان المقالة أو تغيير قيمة بعض المعلمات.

من المهم مراعاة حقيقة أن الخادم غير مطالب بالقيام بالضبط بما هو محدد في الطريقة على الإطلاق. يمكننا إرسال عنوان بعض الصفحات بطريقة DELETE ، لكن هذا لا يعني أن الخادم سيحذفها بالفعل. ولكن ، من الناحية النظرية البحتة ، يمكنه القيام بذلك باستخدام أمر GET. أو لا تقم بتغيير أي شيء ، ولكن في نفس الوقت أرسل البيانات ردًا على POST. فقط لأن المطور قام بتكوينه بهذه الطريقة.

هذا هو المكان الذي يلعب فيه REST ، والذي يقول أن الوقت قد حان للاتفاق على مراعاة النظام ، ووقف الفوضى والقيام بالضبط بما هو موضح في الطريقة. على أقل تقدير ، يجب أن تكون هذه هي المهمة الرئيسية (على الرغم من أنها ليست المهمة الوحيدة بالضرورة). على سبيل المثال ، عند نقل محتوى مقال باستخدام طريقة GET ، يمكنك في نفس الوقت زيادة عداد عدد مشاهداته بمقدار 1.

لذلك ، اكتشفنا مكان البيانات وما الذي يمكن عمله بها. دعنا نذهب إلى أبعد من ذلك ، دعنا نرى المكونات الأخرى التي يمكن أن يحتوي عليها الطلب.


URL Params. هناك حالات لا نعرف فيها سوى جزء من عنوان URL. مثال على ذلك هو المقالات الموجودة على موقع Appmaster.io. عنوان البداية لجميع المقالات هو نفسه - https://appmaster.io/en/blog/. ولكن بعد ذلك يكون لكل مقال عنوانه الخاص ، وبالتالي ، جزءه الفردي الخاص به للإشارة الدقيقة لهذه المقالة المعينة.

في مثل هذه الحالة ، يتم استخدام URL Params. نصف الجزء العام على الفور ، ونترك الباقي ليتم تحديده في العملية. نتيجة لذلك ، تتم كتابة عنوان URL بالشكل https://appmaster.io/ru/blog/:id/

يُكتب الجزء المعروف كما هو ويوضع الجزء المتغير بعد علامة ":". تمت إضافة اسم جزء المتغير هذا (بدون ":") إلى قائمة المعلمات. في هذه الحالة ، يمكن أن يكون هناك عدة أجزاء متغيرة ، وموقعها في أي مكان في عنوان URL.


معلمات الاستعلام . تذكر عندما أرسلنا طلبًا إلى boredapi.com في الوحدة الأولى؟ بالإضافة إلى العنوان ، تم تحديد بيانات إضافية. كان هذا هو Query Params.

تتم كتابتها بعد عنوان URL ويتم فصلها عنه بعلامة "؟" إشارة. يشار إلى اسم المعلمة وعلامة "=" وقيمة المعلمة نفسها. إذا تم استخدام العديد من المعلمات في وقت واحد ، فسيتم فصلها بعلامة "&".

ومع ذلك ، عند تحديد المعلمات في AppMaster ، لا يتعين عليك التفكير في قواعد الطلب. سيتم تنسيق كل شيء بشكل صحيح تلقائيًا. تحتاج فقط إلى تحديد اسم المعلمة نفسها وإضافتها إلى القائمة.

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

خيار آخر هو مفتاح الوصول. ربما تكون قد استخدمت هذا الخيار في الوحدة 1 عند الإشارة إلى Alphavantage. لا يمكن الحصول على البيانات إلا بعد التسجيل وإرسال مفتاح شخصي في معلمات الطلب.

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

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

في معظم الحالات ، تكون الرؤوس اختيارية. حتى في الوحدة الأولى ، قدمنا ​​بالفعل طلبًا لم نحدد فيه أي رؤوس (على الرغم من أن هذا لا يعني أن الطلب قد تم إرساله بالفعل بدونها).

الجسم . طلب الهيئة. عادةً ما يتم الاستغناء عن طلبات GET ، ولكن إذا أردنا إرسال بعض البيانات إلى الخادم ، أو إرسال طلب POST أو PUT ، فسيتم وضع هذه البيانات في نص الطلب. في نفس الوقت ، يمكنك وضع بيانات من أي تعقيد في نص الطلب ، على سبيل المثال ، إرسال ملف فيديو ، ولا تقتصر على بعض الأرقام أو سلسلة نصية.

تعمل الاستجابة التي تأتي من الخادم وفقًا لنفس المخطط تقريبًا. لأسباب واضحة ، لا يحتوي على معلمات طلب ، ولكن تم تضمين الرؤوس والجسم في الاستجابة (على الرغم من أنها قد تكون فارغة).

الاختلاف المهم هو حالة الاستجابة.

رمز الحالة . يأتي في السطر الأول من استجابة الخادم. الحالة عبارة عن رقم مكون من ثلاثة أرقام (الرمز نفسه) ، متبوعًا بعبارة تشرحها.

يمكنك من خلال رمز الحالة معرفة نتائج الطلب وفهم الإجراءات التي يجب اتخاذها بعد ذلك.

جميع رموز الحالة الممكنة مقسمة إلى 5 فئات. يحدد الرقم الأول من الكود الانتماء إلى فئة معينة. دعونا نكسرهم.

1xx - رموز المعلومات. الإبلاغ عن التقدم المحرز في الطلب. في الممارسة الحقيقية ، نادرًا ما يتم استخدامها.

2xx - رموز النجاح. أبلغوا أن كل شيء على ما يرام وتم إكمال الطلب بنجاح. استجابةً لطلب GET ، نتوقع عادةً تلقي رمز 200 (موافق). يرسل طلب PUT الناجح رمز 201 (تم إنشاؤه).

3xx - عمليات إعادة التوجيه. أشر إلى أنه يجب إرسال الطلب إلى عنوان مختلف. مثال على ذلك هو الرمز 301 (تم النقل بشكل دائم) ، مما يشير إلى أن البيانات المطلوبة موجودة الآن في عنوان جديد (يتم تمرير العنوان الجديد نفسه في عنوان الموقع).

4xx - رموز خطأ العميل. أشهرها - 404 (غير موجود) ، تفيد بعدم وجود بيانات ضرورية على العنوان المحدد. الحالات الشائعة الأخرى: 400 (طلب غير صالح ، خطأ في بناء الجملة في الطلب) ، 401 (غير مصرح به ، المصادقة مطلوبة للوصول) ، 403 (ممنوع ، تم رفض الوصول).

5xx - رموز خطأ الخادم. الإبلاغ عن خطأ من جانب الخادم. كمثال: 500 (خطأ داخلي في الخادم ، أي خطأ غير مفهوم لا يمكن أن يُنسب إلى رمز معروف) ، 503 (الخدمة غير متاحة ، يتعذر على الخادم مؤقتًا معالجة الطلب لأسباب فنية)

في هذه المرحلة ، يمكننا أن نفترض أننا تعاملنا مع المعلومات الأساسية لفهم واجهة برمجة تطبيقات REST وهيكل طلبات واستجابات HTTP. يبقى توضيح نقطة واحدة فقط - أنواع البيانات. إذا كنت قد حاولت بالفعل إنشاء طلب API الخاص بك في AppMaster ، فمن المحتمل أنك لاحظت أن جميع البيانات (في المعلمات ، في الرؤوس ، في النص الأساسي) تطلب منك ليس فقط تحديد الاسم ، ولكن أيضًا نوع البيانات.


عادة ما يكون من الواضح جدًا للإنسان كيفية التعامل مع البيانات ، حيث يوجد سياق معين. لنفترض أننا نعلم أن 2 + 2 = 4. نعتقد أن هذه أعداد وأن نتيجة الجمع ستكون رقمًا آخر.

لكنها قد لا تكون أرقامًا ، بل بيانات نصية. ثم يمكن أن تكون نتيجة إضافتهم هي تسلسل السلاسل ويتحول 2 + 2 إلى "22". هنا ، حتى لا يضطر الكمبيوتر إلى التفكير في أي شيء ، هناك إشارة دقيقة لنوع البيانات. وفي الوقت نفسه ، يتم حل المهام الأخرى. على سبيل المثال ، يتم توفير الحماية ضد إدخال بيانات غير صحيحة ؛ في البداية ، لا توجد فرصة لتسجيل عنوان بريد إلكتروني في الحقل المخصص لإدخال أرقام رقم الهاتف.

يوجد عدد كبير جدًا من أنواع البيانات المختلفة ، والآن سننظر في أكثرها أساسية ، وفي وحدات أخرى من الدورة سنتعرف على الباقي.

سلسلة - نوع بيانات السلسلة ، نص عادي بدون تنسيق خاص.

عدد صحيح - نوع بيانات صحيح. يمكن استخدامها للعدادات أو العمليات الحسابية حيث لا تكون هناك حاجة للأرقام الكسرية

Float - رقم الفاصلة العائمة. يتم استخدامه عند الحاجة إلى زيادة الدقة وعدم كفاية القيم الصحيحة.

قد ينشأ هنا سؤال منطقي. ولماذا لا نستخدم Float دائمًا ، فلماذا نحتاج إلى عدد صحيح إذن؟ لكن الدقة الأكبر تتطلب موارد أكثر. بالنسبة لبعض العمليات الحسابية الصغيرة ، قد يكون هذا غير مرئي تمامًا ، ولكن في حالة وجود كميات كبيرة من البيانات ، يمكن أن يؤدي استخدام نوع بيانات معقول إلى تقليل متطلبات طاقة الحوسبة ومساحة القرص بشكل كبير.

Boolean - نوع البيانات المنطقية. أبسط نوع بيانات. يأخذ إحدى القيمتين ، والتي تتم كتابتها على أنها صواب أو خطأ. يمكنك غالبًا رؤية التسمية في شكل 1 (صواب) و 0 (خطأ).


الواجب المنزلي

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

  1. إنشاء طلب إلى BoredAPI. حدد ما لا يقل عن 5 معلمات مختلفة من الوثائق. إرسال عدة طلبات مختلفة ، مع تحديد المعلمات المطلوبة فقط.
  2. قم بإنشاء طلب إلى Alphavantage. استخدم المعلمات للحصول على أسعار العملات المختلفة فيما يتعلق ببعضها البعض.