We have an API GTW that receives a REST request. A preprocessing service is executed on the IS AG to add elements in header. Preprocessing service works with a RestMessageContext.
After preprocessing service, API GTW executes straight routing policy to call the IS backend.
But, RestMessageContext is not visible on the IS backend.
The same operation is realized with SOAP Request, with preprocessing service that works with a MessageContext. In this case, we have MessageContext visible on the IS backend.
Do you know why RestMessageContext is not transmitted to the IS backend?
Both RestMessageContext(for REST)/MessageContext(for SOAP) is applicable only in API Gateway context. Hence it is accessible via IS Service in the policies like Request Processing, Response Processing which are still in API Gateway context.
When a straight through routing (or any other routing) happens, from the time the request is sent to native service and until the response is received by API Gateway, API Gateway is out of context and only the native server is in context. So, even if your native service is still an IS Service, it wouldn’t be able to access RestMessageContext/MessageContext of API Gateway. MessageContext you were able to access for your SOAP native service is a different MessageContext created by your IS for serving that outbound request (request originated with API Gateway as client and your IS as Server). This MessageContext is not the same as the one which you can access in API Gateway’s Request Processing stage using an IS Service.
If your requirement is to access something from RestMessageContext at your native service, you could achieve this by extracting the value you want from the RestMessageContext in your Request Processing stage, and set it in header or query parameters. You can write your native IS Service to access the value via the headers/query we set in Request Processing stage.