Changes to Dynamic Endpoint Sample | Mediation Extensions

The sample shared in [1] is actually a static value hardcoded in the mediation extension (i.e: http://jsonplaceholder.typicode.com/posts/).

Since the functionality is not reflected in the document [1] it would be better to include a sample to get the dynamic behaviour based on incoming requests.

Examples in [2][3] might be helpful for this.

Adding the following notes will be better because while implementing solutions these notes will be important.

1. The dynamic endpoint functionality will be suitable for cases in which the application client can send an attribute in the request which would correlate to the intended endpoint (such as an HTTP transport header or as part of the payload) which can be used in the mediation extension.
2. The mediation extension is applied to all resources of the API. Therefore all resources will contain a similar logic to construct the endpoint.

Additionally, we need the following note in the mediation extension document [4] as well.

1. The mediation extension is applied to all resources of the API.

[1]. https://apim.docs.wso2.com/en/3.2.0/learn/api-gateway/message-mediation/adding-dynamic-endpoints/#adding-dynamic-endpoints

[2]. https://lashan.medium.com/dynamically-setting-the-endpoint-uri-in-wso2-api-manager-83a3a6243ce

[3]. https://blog.lakmali.com/2016/08/dynamic-endpoints-in-wso2-api-manager.html

[4]. https://apim.docs.wso2.com/en/3.2.0/learn/api-gateway/message-mediation/changing-the-default-mediation-flow-of-api-requests/

Start with the dynamic endpoints document at [1] and the mediation extension document at [4], then review the examples linked in [2] and [3]. Update the sample to demonstrate endpoint selection from an incoming request and add the stated scope notes to both documents; done means both pages accurately explain the dynamic behavior and resource coverage.