JavaScript policy recos

[Char-K]

need help or recommendations.

[dchiesa1]

I'm curious why you wish to "handle" these errors in JavaScript.  There are other options.

The simplest option is to  just allow Apigee to pass-through the errors to the client.  In that case, for example, a 415 returned by the target will reach the client, with whatever message was provided by the upstream.  Normally a 415 will say something like "unsupported media type."  It looks like your JS is ... overriding that message?  To what end?   Likewise with 404.  Why override it?  The 404 is pretty clear by itself? 

There are some cases in which you'd like to override (or "mediate"?) the error response sent from the target, aka backend .  Maybe the backend responds with an unclear error message, and you'd like to clarify that.  Or you'd like to consolidate all 4xx errors into 400.   In Apigee, the prescribed way to do that is with FaultRules.  In the FaultRules you can specify conditions (like error.status.code = 415) and then specify what the message ought to be, including status and message.  Check the Apigee docs on "Handling faults."

You could do it all in JavaScript, and I guess your JS looks ok.  but... that approach feels ... slightly unnatural to me, in Apigee. 

But of course I don't understand what you're really trying to do.  What is the purpose of the "handling" is JS? 

I also don't understand what you said about "message validation" - not sure how that comes into play.  Are you saying that you want Apigee to validate the schema of the error message that gets returned by the upstream?  ??  What purpose would that serve?  Do you suppose sometimes the upstream returns "broken" error messages and you want Apigee to log that situation?   Usually the upstream is stable and Apigee doesn't validate responses.  But I suppose there can be exceptions. 

[Char-K]

Hello! 

The reason behind is we need to recreate the same response from another platform as we are moving things to Apigee. And that is why we need to handle the correct and same structure of the response as the one from the prior platform. So we're like copying everything that they have already implemented into Apigee so that there will be no changes with the responses as part of the business requirement. 

And the proxy is directly connected to the backend, so the response is not the actual response, so that is why I need to map some selected fields only.

Also, with regards the schema validation, it is part of the requirement as well, so when the request is broken as what you mentioned, there will be a corresponding response. 

But I'll be taking your suggestion with FaultRule then.

PS: It's really hard working without an architect to be honest.

[dchiesa1]

Ah, gotcha.  

Yes, I empathize with you.  It's important to have an architect on the project!