إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
بالإضافة إلى نمط العميل/الخادم الكلاسيكي، توفر خدمة Azure SignalR مجموعة من واجهات برمجة تطبيقات REST لمساعدتك على دمج وظائف الوقت الحقيقي في البنية بلا خادم.
إشعار
تدعم خدمة Azure SignalR استخدام واجهات برمجة تطبيقات REST فقط لإدارة العملاء المتصلين من خلال ASP.NET Core SignalR. يستخدم العملاء المتصلون من خلال ASP.NET SignalR بروتوكول بيانات مختلف غير مدعوم حاليا.
بنية نموذجية بلا خادم مع Azure Functions
يوضح الرسم التخطيطي التالي بنية نموذجية بلا خادم تستخدم خدمة Azure SignalR مع Azure Functions.
negotiateترجع الدالة استجابة التفاوض وتعيد توجيه جميع العملاء إلى Azure SignalR Service.broadcastتستدعي الدالة واجهة برمجة تطبيقات REST لخدمة Azure SignalR. تبث خدمة Azure SignalR الرسالة لجميع العملاء المتصلين.
في بنية بلا خادم، العملاء لديهم اتصالات مستمرة بخدمة Azure SignalR. نظرا لعدم وجود خادم تطبيق للتعامل مع نسبة استخدام الشبكة، فإن العملاء في LISTEN الوضع . في هذا الوضع، يمكن للعملاء تلقي الرسائل ولكن لا يمكنهم إرسال الرسائل. تقوم خدمة Azure SignalR بقطع اتصال أي عميل يرسل الرسائل لأنها عملية غير صالحة.
يمكنك العثور على عينة كاملة من استخدام خدمة Azure SignalR مع Azure Functions في مستودع GitHub هذا.
تنفيذ نقطة نهاية التفاوض
يجب عليك تنفيذ دالة negotiate ترجع استجابة تفاوض إعادة توجيه بحيث يمكن للعملاء الاتصال بالخدمة.
تتضمن الاستجابة النموذجية للتفاوض هذا التنسيق:
{
"url": "https://<service_name>.service.signalr.net/client/?hub=<hub_name>",
"accessToken": "<a typical JWT>"
}
accessToken يتم إنشاء القيمة من خلال نفس الخوارزمية الموضحة في قسم المصادقة. الفرق الوحيد هو أن المطالبة aud يجب أن تكون هي نفسها url.
يجب عليك استضافة واجهة برمجة تطبيقات التفاوض الخاصة بك بحيث https://<hub_url>/negotiate لا يزال بإمكانك استخدام عميل SignalR للاتصال بعنوان URL للمركز. اقرأ المزيد حول إعادة توجيه العملاء إلى خدمة Azure SignalR في اتصالات العميل.
إصدارات واجهة برمجة تطبيقات REST
يعرض الجدول التالي جميع إصدارات REST API المدعومة. كما يوفر ملف Swagger لكل إصدار من إصدارات واجهة برمجة التطبيقات.
| إصدار API | الحالة | المنفذ | الوثائق | المواصفات |
|---|---|---|---|---|
20220601 |
الأحدث | قياسي | مقالة | ملف Swagger |
1.0 |
Stable | قياسي | مقالة | ملف Swagger |
1.0-preview |
قديم | قياسي | مقالة | ملف Swagger |
يسرد الجدول التالي واجهات برمجة التطبيقات المتوفرة.
| واجهة برمجة التطبيقات (API) | المسار |
|---|---|
| بث رسالة إلى جميع العملاء المتصلين بمركز الهدف | POST /api/v1/hubs/{hub} |
| بث رسالة لجميع العملاء ينتمون إلى المستخدم الهدف | POST /api/v1/hubs/{hub}/users/{id} |
| إرسال رسالة إلى الاتصال المحدد | POST /api/v1/hubs/{hub}/connections/{connectionId} |
| تحقق مما إذا كان الاتصال ب connectionId المحدد موجودا | GET /api/v1/hubs/{hub}/connections/{connectionId} |
| إغلاق اتصال العميل | DELETE /api/v1/hubs/{hub}/connections/{connectionId} |
| بث رسالة إلى جميع العملاء داخل المجموعة المستهدفة | POST /api/v1/hubs/{hub}/groups/{group} |
| تحقق مما إذا كانت هناك أي اتصالات عميل داخل المجموعة المحددة | GET /api/v1/hubs/{hub}/groups/{group} |
| تحقق مما إذا كانت هناك أي اتصالات عميل متصلة للمستخدم المحدد | GET /api/v1/hubs/{hub}/users/{user} |
| إضافة اتصال إلى المجموعة المستهدفة | PUT /api/v1/hubs/{hub}/groups/{group}/connections/{connectionId} |
| إزالة اتصال من المجموعة المستهدفة | DELETE /api/v1/hubs/{hub}/groups/{group}/connections/{connectionId} |
| التحقق مما إذا كان المستخدم موجودا في المجموعة المستهدفة | GET /api/v1/hubs/{hub}/groups/{group}/users/{user} |
| إضافة مستخدم إلى المجموعة المستهدفة | PUT /api/v1/hubs/{hub}/groups/{group}/users/{user} |
| إزالة مستخدم من المجموعة المستهدفة | DELETE /api/v1/hubs/{hub}/groups/{group}/users/{user} |
| حذف مستخدم من جميع المجموعات | DELETE /api/v1/hubs/{hub}/users/{user}/groups |
باستخدام واجهة برمجة تطبيقات REST
المصادقة عبر AccessKey في خدمة Azure SignalR
في كل طلب HTTP، يلزم عنوان تخويل مع رمز ويب JSON المميز (JWT) للمصادقة باستخدام Azure SignalR Service.
خوارزمية التوقيع والتوقيع
HS256، وهي HMAC-SHA256، تستخدم ك خوارزمية التوقيع.
AccessKey استخدم القيمة في سلسلة الاتصال مثيل خدمة SignalR Azure لتوقيع JWT الذي تم إنشاؤه.
المطالبات
يجب تضمين المطالبات التالية في JWT.
| نوع المطالبة | مطلوب | الوصف |
|---|---|---|
aud |
true |
يجب أن يكون نفس عنوان URL لطلب HTTP الخاص بك، وليس بما في ذلك الشرطة المائلة اللاحقة ومعلمات الاستعلام. على سبيل المثال، يجب أن يبدو جمهور طلب البث كما يلي: https://example.service.signalr.net/api/v1/hubs/myhub. |
exp |
true |
وقت الفترة عند انتهاء صلاحية هذا الرمز المميز. |
المصادقة عبر الرمز المميز ل Microsoft Entra
على غرار المصادقة عبر AccessKey، مطلوب JWT لمصادقة طلب HTTP باستخدام رمز Microsoft Entra المميز.
الفرق هو أنه في هذا السيناريو، ينشئ معرف Microsoft Entra JWT. لمزيد من المعلومات، راجع التعرف على كيفية إنشاء رموز Microsoft Entra المميزة.
يجب أن يكون https://signalr.azure.com/.defaultنطاق بيانات الاعتماد المستخدم .
يمكنك أيضا استخدام التحكم في الوصول استنادا إلى الدور (RBAC) لتخويل الطلب من العميل أو الخادم إلى Azure SignalR Service. لمزيد من المعلومات، راجع تخويل الوصول باستخدام معرف Microsoft Entra لخدمة Azure SignalR.
واجهة برمجة تطبيقات REST المتعلقة بالمستخدم
لاستدعاء واجهة برمجة تطبيقات REST المتعلقة بالمستخدم، يجب على كل عميل من عملائك التعرف على خدمة Azure SignalR. وإلا، لا يمكن ل Azure SignalR Service العثور على الاتصالات الهدف من معرف المستخدم.
يمكنك تحقيق تعريف العميل عن طريق تضمين nameid مطالبة في JWT لكل عميل عند الاتصال بخدمة Azure SignalR. ثم تستخدم خدمة Azure SignalR قيمة المطالبة nameid كمعرف المستخدم لكل اتصال عميل.
عينة
في مستودع GitHub هذا، يمكنك العثور على تطبيق وحدة تحكم كامل لتوضيح كيفية إنشاء طلب REST API HTTP يدويا في خدمة Azure SignalR.
يمكنك أيضا استخدام Microsoft.Azure.SignalR.Management لنشر الرسائل إلى خدمة Azure SignalR باستخدام واجهات مماثلة ل IHubContext. يمكنك العثور على عينات في مستودع GitHub هذا. لمزيد من المعلومات، راجع Azure SignalR Service Management SDK.
القيود
حاليا، طلبات واجهة برمجة تطبيقات REST لها القيود التالية:
- يبلغ حجم الرأس 16 كيلوبايت كحد أقصى.
- حجم الجسم هو 1 ميغابايت كحد أقصى.
إذا كنت تريد إرسال رسائل أكبر من 1 ميغابايت، فاستخدم Service Management SDK مع persistent الوضع .