API によって公開されているリソースの一部にポリシーを適用する場合には、正規表現 (regex) を指定することで、複数のパスを含めることができます。正規表現の式は、ポリシーの URI template regex 項目で指定できます。
URI template regex を設定する場合は、アプリケーションを実装 (またはプロキシを使用) する Mule Runtime Engine (Mule) アプリケーションのベースパスを考慮する必要があります。その理由は、Mule 4 のリソースレベルポリシーは、API がデプロイされている場所に依存するためです。
この図は、ポリシーを適用するリソースサブセットを指定するメソッドのリストを示しています。
この API 仕様は、次の Mule アプリケーションで実装されています。
<api-gateway:autodiscovery apiId="1" flowRef="proxy"/>
<http:listener-config name="httpConfig" basePath="api">
<http:listener-connection host="localhost" port="80"/>
</http:listener-config>
<flow name="proxy">
<http:listener config-ref="httpConfig" path="v1/*" />
<logger />
</flow>
この例では、http:listener-config は basePath 属性と、パス v1/ の最後にある の前に追加パス v1 の両方を定義しています。これら 2 つのパスを連結した /api/v1 がベースパスとして参照されます。
以後、resource-1 をポリシーで保護するには、リソースレベルのポリシーを使用する必要があります。そのため、ポリシーを適用するときに指定する URI テンプレート正規表現にはベースパスを含める必要があります。
URI テンプレート正規表現の設定方法を下図に示します。
API のアセットタイプが RAML または OAS である場合、Preview Resource Matching オプションは実際のランタイム動作とは異なり、どのリソースとも一致したとは示しません。
また、正規表現を使用することで、ベースパス (例: .*/resource-1) を明示的に指定する必要がなくなります。ただし、同じ名前のリソースが API 定義の別のレベルにも存在する場合は、正規表現によってそれらすべてと一致してしまうため問題が発生します。つまり、正規表現が /api/v1/resource-1 と /api/v1/resources/resource-1 の両方と一致するため、結果が曖昧になってしまいます。