في عام 2005، كتب جيسي جيمس جاريت مقالًا بعنوان "Ajax - نهج جديد لتطبيقات الويب"، والذي وصف فيه تطبيقًا يسمى Ajax (تقنية JavaScript+XML غير المتزامنة). تتضمن هذه التقنية إرسال طلب إلى الخادم للحصول على بيانات إضافية دون تحديث الصفحة، مما يؤدي إلى تجربة مستخدم أفضل. يشرح غاريت كيف تغير هذه التقنية نموذج النقر والانتظار التقليدي الذي استمر منذ ولادة الويب.
التقنية الرئيسية التي دفعت Ajax إلى المسرح التاريخي هي كائن XMLHttpRequest (XHR). قبل ظهور XHR، كان لا بد من تحقيق الاتصال بأسلوب Ajax من خلال بعض التقنيات السوداء، وذلك باستخدام الأجزاء المخفية أو الأجزاء المضمنة بشكل أساسي. يوفر XHR واجهة معقولة لإرسال طلبات الخادم والحصول على الاستجابات. يمكن لهذه الواجهة الحصول على بيانات إضافية من الخادم بشكل غير متزامن، مما يعني أنه يمكن للمستخدمين الحصول على البيانات دون تحديث الصفحة. بعد الحصول على البيانات من خلال كائن XHR، يمكنك استخدام طرق DOM لإدراج البيانات في صفحة الويب.
تعتبر واجهة برمجة تطبيقات كائن XHR صعبة الاستخدام بشكل عام، وسرعان ما أصبحت Fetch API معيارًا بديلاً أكثر حداثة لـ XHR بعد ولادتها التلقائية. تدعم Fetch API الوعود المجدولة وسلاسل الخدمة (عمال الخدمة)، وأصبحت شبكة ويب قوية للغاية أداة التطوير.
أحد القيود الرئيسية لاتصالات Ajax من خلال XHR هو سياسة الأمان عبر الأصل. افتراضيًا، يمكن لـ XHR الوصول فقط إلى الموارد الموجودة في نفس المجال مثل الصفحة التي بدأت الطلب. يمنع تقييد الأمان هذا سلوكًا ضارًا معينًا. ومع ذلك، تحتاج المتصفحات أيضًا إلى دعم الوصول القانوني عبر الأصل.
تحدد مشاركة الموارد عبر الأصل (CORS) كيفية تنفيذ المتصفحات والخوادم للاتصال عبر الأصل. الفكرة الأساسية وراء CORS هي استخدام رؤوس HTTP المخصصة للسماح للمتصفح والخادم بفهم بعضهما البعض لتحديد ما إذا كان الطلب أو الاستجابة يجب أن تنجح أو تفشل.
بالنسبة للطلبات البسيطة، مثل طلبات GET أو POST، لا توجد رؤوس مخصصة، ويكون نص الطلب من النوع النصي/العادي، وسيكون لهذه الطلبات رأس إضافي يسمى Origin عند إرسالها. يحتوي رأس الأصل على المصدر (البروتوكول، اسم المجال، المنفذ) للصفحة التي ترسل الطلب حتى يتمكن الخادم من تحديد ما إذا كان سيتم تقديم استجابة له أم لا.
تدعم المتصفحات الحديثة CORS أصلاً من خلال كائن XMLHttpRequst، والذي يتم تشغيله تلقائيًا عند محاولة الوصول إلى الموارد من أصول مختلفة. لإرسال طلب إلى أصل في مجال مختلف، يمكنك استخدام كائن XHR قياسي وتمرير عنوان URL مطلق إلى طريقة open()، على سبيل المثال:
Let xhr = new XMLHttpRequest();xhr.onreadystatechange = function(){ إذا (xhr.readyState == 4){ إذا ((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304){ تنبيه (xhr.reaponseText)؛ }آخر{ تنبيه("الطلب غير ناجح:"+xhr.status); } }};xhr.open("get,"http://www.nezha.con/page/",true);xhr.send(null);
تسمح كائنات XHR عبر المجال بالوصول إلى خصائص الحالة ونص الحالة، و تسمح أيضًا بطلبات المزامنة بأن تفرض كائنات XHR عبر المجال أيضًا بعض القيود الإضافية لأسباب أمنية.
لا يمكنك استخدام setRequestHeader () لتعيين رؤوس مخصصة؛
ولا يمكنك إرسال واستقبال ملفات تعريف الارتباط؛
تُرجع طريقة getAllResponseHeaders () دائمًا سلسلة فارغة؛
نظرًا لاستخدام نفس الواجهة لطلبات النطاق نفسه والطلبات عبر النطاق، فمن الأفضل أن يتم ذلك الوصول إلى الموارد المحلية استخدم عناوين URL النسبية واستخدم عناوين URL المطلقة عند الوصول إلى الموارد البعيدة، وهذا يمكن أن يميز سيناريوهات الاستخدام بشكل أكثر وضوحًا وتجنب مشكلة الوصول المقيد إلى معلومات الرأس أو ملف تعريف الارتباط عند الوصول إلى الموارد المحلية.
يستخدم CORS آلية التحقق من الخادم تسمى طلب الاختبار المبدئي، مما يسمح باستخدام رؤوس مخصصة وطرق أخرى غير GET وPOST وأنواع محتوى نص الطلب المختلفة. عند إرسال طلب يتضمن أحد الخيارات المتقدمة المذكورة أعلاه، يتم إرسال طلب الاختبار المبدئي أولاً إلى الخادم. يتم إرسال هذا الطلب باستخدام طريقة OPTIONS ويحتوي على الرؤوس التالية:
الأصل: نفس طلب بسيط؛
Access-Control-Request-Method: الطريقة التي تريد استخدامها؛
Access-Control-Request-Headers: (اختياري) فاصلة - قيم منفصلة لاستخدام قائمة الرؤوس المخصصة
يمكن لـ Fetch API تنفيذ جميع مهام كائن XMLHttpRequest، ولكنها أسهل في الاستخدام، والواجهة أكثر حداثة، ويمكن استخدامها في أدوات الويب مثل خيوط عامل الويب. يمكن أن يختار XMLHttpRequest أن يكون غير متزامن، بينما يجب أن تكون Fetch API غير متزامنة.
يتم عرض طريقة الجلب () في النطاق العام، بما في ذلك مؤشر ترابط تنفيذ الصفحة الرئيسية والوحدات النمطية وخيوط العامل. يؤدي استدعاء هذه الطريقة إلى قيام المتصفح بإرسال طلب إلى عنوان URL المحدد.
1. طلب الإرسال
يحتوي fetch() على إدخال معلمة واحد مطلوب فقط. في معظم الحالات، تكون هذه المعلمة هي عنوان URL للحصول على المورد، وترجع هذه الطريقة وعدًا:
Let r = fetch('/bar');console.log(r);//
تنسيق عنوان URL للوعد<pending> (المسار النسبي) ، والمسارات المطلقة، وما إلى ذلك) يتم تفسيرها بنفس طريقة تفسير كائنات XHR.
عند اكتمال الطلب وتوافر الموارد، ستتم معالجة كائن الاستجابة. هذا الكائن عبارة عن تغليف لواجهة برمجة التطبيقات (API) التي يمكن من خلالها الحصول على الموارد المقابلة. استخدم خصائص وأساليب هذا الكائن للحصول على الموارد وفهم الاستجابة وتحويل موازنة التحميل إلى نموذج مفيد.
2. اقرأ الرد إن أبسط طريقة لقراءة محتوى الرد هي الحصول على المحتوى بتنسيق نص عادي، فقط استخدم طريقة text(). تُرجع هذه الطريقة وعدًا يقضي باسترداد محتويات المورد بالكامل.
3. التعامل مع رموز الحالة وفشل الطلب
تدعم Fetch API التحقق من حالة الاستجابة من خلال خصائص الحالة ونص الحالة الخاصة بالاستجابة. عادةً ما تنتج الطلبات التي تحصل على استجابة بنجاح رمز حالة بقيمة 200.
4. أوضاع طلب الجلب الشائعة:
إرسال بيانات JSON،
وإرسال المعلمات في نص الطلب،
وإرسال الملفات
، وتحميل ملفات Blob
، وإرسال طلبات عبر المجال،
وطلبات المقاطعة
مقبس Websocket الهدف من websocket هو تحقيق الإرسال المزدوج الكامل والثنائي. طريقة التواصل مع الخادم من خلال اتصال طويل الأمد. عند إنشاء websocket في JavaScript، يتم إرسال طلب HTTP إلى الخادم لتهيئة الاتصال. بعد استجابة الخادم، يتحول الاتصال من بروتوكول HTTP إلى بروتوكول websocket باستخدام رأس الترقية في HTTP، مما يعني أنه لا يمكن تنفيذ websocket من خلال خادم HTTP قياسي، ولكن يجب استخدام خادم خاص يدعم هذا البروتوكول.
نظرًا لأن websocket يستخدم بروتوكولًا مخصصًا، فقد تغير نظام URL قليلاً. ولم يعد من الممكن استخدام http:// أو https://، ولكن يجب استخدام ws:// وwss://. الأول هو اتصال غير آمن والثاني هو اتصال آمن. عند تنفيذ عناوين URL لـ websocket، يجب تضمين نظام URL لأنه من الممكن دعم مخططات إضافية في المستقبل.
تتمثل ميزة استخدام بروتوكول مخصص بدلاً من بروتوكول HTTP في أنه يمكن للعميل والخادم إرسال القليل جدًا من البيانات دون التسبب في أي عبء على HTTP. إن استخدام حزم البيانات الأصغر حجمًا يجعل مقابس الويب مثالية لتطبيقات الأجهزة المحمولة حيث تكون مشكلات النطاق الترددي ووقت الاستجابة كبيرة. عيب استخدام بروتوكول مخصص هو أن تعريف البروتوكول يستغرق وقتًا أطول من تعريف JavaScript API الذي تدعمه جميع المتصفحات الرئيسية.