Has anything changed regarding capabilities to transform responses since March? Currently this seems to be a blocker preventing us from using Tyk.
Example: We have an internal microservice to manage clusters. We call it like this to create a new cluster:
POST /v1/clusters/
Content-type: application/json
{
"details": "..."
}
The service responds like this:
HTTP/1.1 201 Created
Location: /v1/clusters/new-cluster-id/
Content-type: application/json
{
"code": "CLUSTER_CREATED",
"message": "A new cluster with ID 'new-cluster-id' is has been created."
}
Here, the location header contains is the details URI of the new cluster.
We would like to publish this endpoint as POST /v4/clusters/
, and the detail URL returned in the Location
header should be adapted accordingly, like:
POST /v4/clusters/
Content-type: application/json
{
"details": "..."
}
Response
HTTP/1.1 201 Created
Location: /v4/clusters/new-cluster-id/
Content-type: application/json
{
"code": "CLUSTER_CREATED",
"message": "A new cluster with ID 'new-cluster-id' is has been created."
}
I would expect this to be not an uncommon requirement, so I am a bit puzzled to see that Tyk middleware scripting only affects the request.
Regarding response header modification, I found Fixing response headers that leak upstream server data which seems to allow to adapt the host name and port, but not the path in a Location
header.
While the example above only would need adaptation of a header, we also have lots of examples where the body should be modified, too. For example to remove details that shouldn’t be published to certain users.
Also I’m wondering what the section A note on response modifying middleware is about, really. Can you point me to an example?
So basically, I’d be happy for some guidance on how we could solve our case in Tyk Is there any other way than “proxy the request yourself to process the response before it hits the user”? Thanks!