Our old backend uses PHP directly so exposes URLs like this…
GET /foo/bar.php?param=mumble
We want to isolate API consumers from that sort of implementation detail (as we will probably be changing the backend in future) so we would like to have…
GET /foo/bar?param=mumble GET /foo/bar.php?param=mumble on the backend.
The documentation explicitly states that putting the following in an AssignMessage policy should acheive the desired result…
<Set>
<Path>/a/b/c</Path>
</Set>
But no matter where I put it in the flow, Apigee seems to use the public facing path to talk to the backend. I have seen various other examples involving hacking around with target.url and target.copy.pathsuffix but I haven’t found anything which works for me.
You can either use AssignMessage or a simple JS script policy to change the target URL. You need to have these policies under the TargetEndPoint flow, otherwise you don’t see it work.
Yes, and also, if you want to eliminate the proxy path from the target path, do not forget to set the context variable target.copy.pathsuffix to false. This also must be done in the target flow.
Thanks all. It seems that the documentation in this case is not correct and the only way to do it is via target.url, in the target flow as @sudheendra1 suggested (which isn’t very pretty)
It does not look like `target.copy.pathsuffix’ is required in this case. It seems to only have an effect for me when I used Set/Path but not when I set the url directly.
The path that you set in the AssignMessage policy will get overwritten unless you also set target.copy.pathsuffix to false (as @Dino points out). In the target execution phase target.copy.pathsuffix is checked - if it is true (the default value) then the default path is used regardless of what you had previously done in the AssignMessage policy.
When you change the value of target.url via the AssignVariable policy - Apigee creates a variable (dynamic.target) which essentially acts the same as target.copy.pathsuffix being set to false. The target execution will not overwrite the path when dynamic.target exists.
While this may not be entirely consistent behavior, it is the way the system functions today.
The bug mentioned @sgilson still occurs at this date. Will it ever be fixed, or will the documentation be updated to indicate that some other technique should be used?
@Birute Awasthi There are couple of bugs related to this feature. I have already bumped up the priority on those since it seems to be impacting multiple folks. However I don’t have an ETA on the fixes yet.
While the methods explained here work for a normal endpoint, nothing seems to get the job done when using ScriptTarget instead of HTTPTargetConnection.