إخطارات التقدم من خدمة HTTP/REST
https://stackoverflow.com/questions/1043883
-
20-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أنا أعمل على تطبيق ويب يرسل المهام إلى نظام رئيسي/عامل يقوم بتوزيع المهام على أي من سلسلة من مثيلات العامل.يتم تشغيل قائمة انتظار العمل الرئيسية كعملية منفصلة (على جهاز منفصل تمامًا) ويتم إرسال المهام إلى الرئيسي عبر طلبات HTTP/REST.بمجرد إرسال المهام إلى قائمة انتظار العمل، يمكن لتطبيقات العميل إرسال طلب HTTP آخر للحصول على معلومات حالة المهام.
بالنسبة لتطبيق الويب الخاص بي، أود أن يوفر نوعًا من عرض شريط التقدم الذي يمنح المستخدم بعض المؤشرات حول المدى الذي وصلت إليه معالجة المهام.الطريقة الواضحة لتنفيذ ذلك هي استخدام أداة قياس تقدم AJAX التي تقوم بشكل دوري باستقصاء قائمة انتظار العمل لمعرفة حالة المهام التي تم إرسالها.سؤالي هو: هل هناك طريقة أفضل لتحقيق ذلك دون الاقتراع المتكرر؟
لقد فكرت في جعل تطبيق الويب الخاص بالعميل يفتح مقبس خادم يمكنه من خلاله الاستماع إلى الإشعارات من سيد العمل.فكرة أخرى مماثلة لدي هي استخدام XMPP أو بروتوكول مشابه لإشعارات الحالة.(بالطبع، سيحتاج النظام الرئيسي/العامل إلى التحديث لتقديم الإشعارات في كلتا الحالتين ولكنني أملك الكود الخاص بذلك حتى أتمكن من إجراء أي تحديثات ضرورية بنفسي.)
هل لديك أي أفكار حول أفضل طريقة لإعداد نظام إعلام مثل هذا؟هل يستحق الجهد الإضافي المبذول كل هذا العناء، أم أن حل الاقتراع البسيط هو الحل الأمثل؟
المحلول
أعتقد أن ذلك يعتمد على عدة عوامل
- مدى دقة التعليقات (1 بالمائة، 5 بالمائة، 50 بالمائة)
التعليقات الدقيقة تجعل الأمر يستحق متابعة نوع ما من شريط التقدم ودفع أسلوب المذنب.إذا كنت لا تستطيع إلا أن تقول "مشغول..."يتمسك...اوشكت على الوصول...تم ذلك" ثم من المؤكد أن إجراء استطلاع بسيط لـ ajax "هل وصلنا إلى هناك بعد" أسهل في البرمجة. - مدى الوقت الذي يجب أن يرى فيه العميل الرسالة "تم".
- المدة التي تستغرقها كل مهمة (ثانية واحدة، 10 ثوانٍ، 10 دقائق)
1 ثانية تجعل الأمر مثيرًا للجدل بعض الشيء.10 ثواني تجعل الأمر يستحق ذلك.10 دقائق تعني أنه من الأفضل أن تقترح على المستخدم الذهاب لاستراحة لتناول القهوة :-) - كم عدد الطلبات المتزامنة سيكون هناك
ما لم يكن لديك خادم "خاص"، تميل أنظمة أسلوب الدفع المباشر إلى استهلاك الاتصالات وسيتم الوصول إلى الحد الأقصى بسرعة كبيرة.قد يؤدي الاضطرار إلى استخدام المزيد من خوادم الويب للحصول على شريط تقدم رائع إلى الإضرار بالميزانية.
لقد حصلت على بعض التعليمات البرمجية النموذجية 871184 الذي يدل على يد مدحرجة "الإطار إلى الأبد" والذي يبدو أنه يعمل بشكل جيد.المشروع الذي قمت بتطويره من أجله لم يتم تنفيذه بكل هذه الصعوبة، حيث تستغرق العمليات بضع ثوانٍ ويمكننا إعطاء نسبة مئوية دقيقة جدًا.يستخدم الكود asp.net وjquery، لكن التقنيات العامة ستعمل مع أي خادم أو إطار عمل جافا سكريبت.
يحرر مثل جون كما يشير، فإن الإبلاغ عن الحالة ربما لا يكون مهمة خدمة RESTful.ولكن لا يوجد ما يشير إلى أنه لا يمكنك فتح إطار iframe على العميل الذي يرتبط بصفحة على الخادم الذي يستقصي الخدمة.تقول النظرية أن الخادم والخدمة سيكونان على الأقل أقرب إلى بعضهما البعض :-)
نصائح أخرى
الاقتراع
يستمر العميل في استقصاء الخادم للحصول على حالة الاستجابة.
الايجابيات
- أن تكون RESTful حقًا يعني أنه قابل للتخزين المؤقت والقابل للتوسع.
سلبيات
- ليست أفضل استجابة إذا كنت لا ترغب في استطلاع رأي الخادم الخاص بك أكثر من اللازم.
اتصال مستمر
لا يقوم الخادم بإغلاق اتصال HTTP الخاص به مع العميل حتى تكتمل الاستجابة.يمكن للخادم إرسال الحالة المتوسطة من خلال هذا الاتصال باستخدام أجزاء HTTP المتعددة.
المذنب هو الإطار الأكثر شهرة لتنفيذ هذا السلوك.
الايجابيات
- أفضل استجابة، وإخطارات في الوقت الفعلي تقريبًا من الخادم.
سلبيات
- حد الاتصال محدود على خادم الويب، وقد يؤدي إبقاء الاتصال مفتوحًا لفترة طويلة جدًا، في أفضل الأحوال، إلى تحميل الخادم الخاص بك، وفي أسوأ الأحوال، إلى فتح الخادم لهجمات رفض الخدمة.
العميل كخادم
قم بإجراء تحديثات حالة نشر الخادم والرد على العميل كما لو كان تطبيق RESTful آخر.
الايجابيات
- وأفضل ما في العالم هو أنه لا يتم إهدار أي موارد في انتظار الاستجابة، سواء على الخادم أو على جانب العميل.
سلبيات
- أنت بحاجة إلى خادم HTTP كامل ومكدس تطبيق ويب على العميل
- ستعيق جدران الحماية وأجهزة التوجيه التي تحتوي على الافتراضي "لا توجد اتصالات واردة على الإطلاق" الطريق.
لا تتردد في التعديل لإضافة أفكارك أو طريقة جديدة!
ورأيي هو أن العصا مع الحل الاقتراع، ولكن قد تكون مهتمة في هذه المقالة ويكيبيديا على HTTP دفع التقنيات.
وREST تعتمد على HTTP، وهو بروتوكول الطلب / استجابة. أنا لا أعتقد أنك سوف تحصل على الخادم HTTP النقي استدعاء العميل مرة أخرى مع الوضع.
وعلاوة على ذلك، وضع التقارير ليست وظيفة الخدمة. والامر متروك للعميل لتحديد موعد، أو إذا كان يريد ذكرت الراهن.
المذنب . يمكنك تقديم طلب واحد لخادم والكتل الخادم وتتولى اتصال مفتوح حتى يحدث التحديث في الوضع. وعندما يحدث ذلك يتم إرسال استجابة وملتزمة. المتصفح يتلقى هذا الرد، ويعالج ذلك وعلى الفور إعادة طلبات URL نفسه. والنتيجة هي أن الأحداث التي دفعت إلى المتصفح. هناك إيجابيات وسلبيات، وأنه قد لا يكون مناسبا لجميع حالات الاستخدام ولكن من شأنه أن يوفر معظم الوقت المناسب تحديثات.
ويمكنك أيضا استخدام الإطار من منعش الذات، ولكن الدعوة AJAX هو أفضل بكثير. أنا لا أعتقد أن هناك أي وسيلة أخرى.
وPS: إذا كنت فتح مأخذ التوصيل من العميل، وهذا لن يتغير كثيرا - من شأنه أن متصفح PHP تظهر الصفحة كما لا يزال "تحميل"، وهي ليست سهلة الاستعمال جدا. (على افتراض انك ستدفع أو عازلة دافق لديها أشياء أخرى عرض من قبل)
