عنوان 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.
نعم.
بناءً على شكل الحقول ، أظن أنك كنت تخطط لتنفيذ ذلك باستخدام 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}
، والتي تحتوي على متغير واحد فقط لكل لقطة ، وهي جيدة تمامًا.
هذه الحزمة هي حزمة داخلية ولا يمكن استيرادها خارج الحزمة الرئيسية ، ولكن هذا يجب أن يفعل ذلك.
تحرير: تعرض الحزمة الرئيسية الوظيفة أيضًا.