Lorawan-stack: دعم متغير مخصص في عناوين URL لبرنامج Webhook

تم إنشاؤها على ١٦ يوليو ٢٠١٩  ·  9تعليقات  ·  مصدر: TheThingsNetwork/lorawan-stack

ملخص

عنوان URL النهائي للخطاف على الويب ثابت حاليًا ، ولا يدعم المتغيرات المخصصة مثل JoinEUI و DevID و DevEUI و DevAddr . يجب أن تكون النتيجة أن عنوان URL الأساسي لخطاف الويب مثل http://example.com/app1/wh1 يمكن أن يصبح http://example.com/app1/wh1/{{.DevEUI}} ويسمح لنقطة نهاية Webhook بتوجيه الارتباطات الصاعدة بشكل أفضل. يجب أن يكون هذا قابلاً للتطبيق أيضًا داخل عناوين URL المحددة للرسالة (رسالة الارتباط الصاعد ، الارتباط الهابطة في قائمة الانتظار وما إلى ذلك)

لماذا نحتاج هذا؟

سيسمح هذا بتوجيه Webhooks بشكل أفضل ويمكننا أيضًا من كتابة عمليات تكامل معينة (مثل OpenSensors) فقط كـ WebHooks.

ما هو موجود بالفعل؟ ماذا ترى الآن؟

دعم عنوان URL الثابت - يتم ربط BaseURL بالموضوع بناءً على نوع الارتباط الصاعد ، ولكن لا توجد حقول توجيه مخصصة.

ما المفقود؟ ماذا تريد ان ترى؟

حقول التوجيه المخصصة {{.AppEUI}} ، {{.JoinEUI}} ، {{.DevID}} ، {{.DevEUI}} ، {{.DevAddr}} .

بيئة

غير قابل للتطبيق.

كيف تقترح تنفيذ هذا؟

استبدل المتغيرات المخصصة في عنوان URL بعد حدوث رابط URL الأساسي + رابط التكوين في newRequest.

هل يمكنك القيام بذلك بنفسك وإرسال طلب سحب؟

نعم.

application server in progress

ال 9 كومينتر

بناءً على شكل الحقول ، أظن أنك كنت تخطط لتنفيذ ذلك باستخدام text/template . إذا كان الأمر كذلك بالفعل ، فالرجاء الانتباه إلى حقيقة أن تحليل القوالب وتنفيذها (خاصةً إذا لم يكن عنوان URL الأساسي فحسب ، بل المسار أيضًا) على كل ارتباط صاعد يمكن أن يكون مكثفًا للغاية للموارد.
تأكد أيضًا من استخدام بنية محدودة جدًا سيتم تنفيذ القالب بها. استخدم الأنواع الأولية فقط (لذا قم بتحويل جميع EUIs / DevAddr إلى سلاسل) ، وتجنب المؤشرات.

أعتقد أنه يمكننا تخزين القالب نفسه مؤقتًا باستخدام معرف Webhook + updated_at لتجنب إعادة تجميع القالب في كل مرة. كما أن الأمر كذلك بالفعل هو أن السلاسل فقط يجب أن يتم تمريرها إلى القالب نفسه (وأنا أفضل ألا نستخدم أي شيء آخر خارج المعرفات).

أعتقد خيارين.

  • استخدم text/template ببنية بسيطة جدًا لحالة الاستخدام هذه. أي ، لا *ttnpb.ApplicationUp لكن WebhookTemplateFields بالأشياء التي ندعمها فقط
  • استخدم استبدال السلسلة في الحقول المعروفة. بسرعة فائقة ، نفس النتيجة

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

إذا أردنا الاحتفاظ بقواعد التحقق من الصحة كما هي ، فيمكننا التفكير في استخدام عناصر نائبة مثل $app_id . بهذه الطريقة لن تكون العناصر النائبة صالحة في المضيف (لأننا لا نريد ذلك) ، لكنها ستكون صالحة في المسار (أعتقد أن $ مسموح به في مسارات URL ، نحتاج إلى التحقق من ذلك ).

$ صالح كجزء من المضيف والمسار وفقًا لقسم RFC3986 2.2 . مع ما يقال ، لسنا مجبرين على تحليل الجزء المضيف من url.URL .

الصيغة القياسية (وفقًا لـ RFC 6570 ، انظر 1.2 و 2.2) لقوالب URI هي {[operator]variable-list} . نظرًا لأننا نعمل في منطقة ساخنة ، أعتقد أن هذا مبرر جيد للتخلي عن المشغلين (لأنهم سيتطلبون معالجة موسعة) ، والسماح بمتغير واحد فقط. هذا يسمح لنا باستخدام string.ReplaceAll بدون إعادة اختراع العجلة.

ماذا تقصد ب "السماح بمتغير واحد"؟

أعتقد أيضًا أن تجربة المستخدم من الأفضل عدم استخدام text/template ، بصرف النظر عن الأداء. أنا بخير مع أسماء المتغيرات بنمط PHP.

يسمح المعيار المذكور أعلاه بتعبيرات مثل {appEUI,devEUI} ، والتي لن تسمح لنا باستخدام استبدال سلسلة بسيطة. لاحظ أنني لم أمنع تعبيرات مثل {appEUI}/{devEUI} ، والتي تحتوي على متغير واحد فقط لكل لقطة ، وهي جيدة تمامًا.

هذه الحزمة هي حزمة داخلية ولا يمكن استيرادها خارج الحزمة الرئيسية ، ولكن هذا يجب أن يفعل ذلك.
تحرير: تعرض الحزمة الرئيسية الوظيفة أيضًا.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات