Thanks for the response, @matiasb.
I’m not sure if the Response Body Transform will suffice as we’re wanting to do more complex transform based on specific details of the response (presence of headers and/or pattern in response body), but do you have any more detail or examples of response transform templates?
ReturnsOverride approach, what drawbacks should be considered if starting to do all HTTP requests through the plugin as opposed to having the gateway perform them? A few concerns that jump to mind include:
- Wouldn’t the plugin need to duplicate configuration/logic for enforcing timeouts?
- How does concurrency in a plugin work? I assume the gateway has much logic for multiple requests executing concurrently and performing appropriate request pooling for proxying the request to the backend server.
- How would the plugin know which backend to send requests to if in a load balanced scenario?
ReturnOverrides seems like a poor man’s way of accomplishing this as it would need to handle all logic to proxy the request to the backend server. Do you know if full support for response processing is on the roadmap for the Tyk? We’d expect to be able to process the response of APIs (before sending back to client) in the same way we’re able to process the request (before it is sent to backend).
Our scenario is that we’re wanting to be able to modify the Tyk user session based on some response scenarios. As an example, if a user has access to the endpoint
CREATE /api/blogs and uses it to create a “blog” item, we would want to have the plugin detect this scenario so that the user can be granted access to that API (e.g.
GET /api/blogs/123). Doing this at the gateway is desired as the individual APIs can be kept purely focused on the service and not need to concern with any authentication/authorization.