Lorawan-stack: WebhookURLでのカスタム変数のサポート

フィールドがどのように見えるかに基づいて、これをtext/templateで実装することを計画していたと思います。 その場合は、すべてのアップリンクでテンプレートを解析して実行すると（特に、ベースURLだけでなくパスでもある場合）、リソースを大量に消費する可能性があることに注意してください。
また、テンプレートが実行される非常に限定された構造体を使用するようにしてください。 プリミティブ型のみを使用し（したがって、すべてのEUI / DevAddrを文字列に変換します）、ポインターは避けます。

毎回テンプレートを再コンパイルすることを避けるために、Webhook ID + updated_atを使用してテンプレート自体をキャッシュできると思います。 また、実際には、文字列のみをテンプレート自体に渡す必要があります（そして、識別子以外のものは使用しないことをお勧めします）。

私は2つの選択肢があると思います。

• このユースケースに固有の非常に単純な構造体でtext/templateを使用します。 つまり、 *ttnpb.ApplicationUpを渡すのではなく、私たちがサポートするものだけでWebhookTemplateFieldsを渡します
• 既知のフィールドで文字列置換を使用します。 超高速、同じ結果

2番目に進む場合は、Goテンプレート構文をまったく使用しないでください。混乱するだけです（ドットがスペースで埋められているのはなぜですか？）。

検証ルールを同じに保ちたい場合は、 $app_idのようなプレースホルダーの使用を検討できます。 そうすれば、プレースホルダーはホストでは有効になりませんが（これは望ましくないため）、パスでは有効になります（URLパスでは$が許可されていると思います。これを確認する必要があります。 ）。

$は、 RFC3986セクション2.2に従って、ホストとパスの両方の一部として有効です。 そうは言っても、 url.URLのホスト部分を解析する必要はありません。

URIテンプレートの標準（ RFC 6570による、1.2および2.2を参照）構文は{[operator]variable-list}です。 私たちはホットスポットで作業しているので、これは演算子を削除し（拡張処理が必要になるため）、変数を1つだけ許可するのに十分な理由だと思います。 これにより、車輪の再発明をしなくてもstring.ReplaceAllを使用できます。

「1つの変数を許可する」とはどういう意味ですか？

また、ユーザーエクスペリエンスの観点からは、パフォーマンスへの影響は別として、 text/templateを使用しない方がよいと思います。 PHPスタイルの変数名で大丈夫です。

上記の標準では、 {appEUI,devEUI}などの式が許可されますが、単純な文字列置換を使用することはできません。 {appEUI}/{devEUI}のような、キャプチャごとに1つの変数しかなく、完全に問題のない式を禁止しなかったことに注意してください。

これはどう？

これは内部パッケージであり、メインパッケージの外部にインポートすることはできませんが、これでインポートできます。
編集：メインパッケージは関数も公開します。