First, make a visual studio webapi project, straight from the webAPI template. Publish it to an azure website. Turn on remote debugging, and log streaming.
This gives, for us
Now we setup the API gateway, in azure. Of course, it wraps that “source API”. We can use the testing console to issue an web service call to the *wrapped* API endpoint – that shows up in the visual studio output windows – that reflects the lots streams from the source processes API endpoint hosted in Azure websites (SEE above)
Once you know how, the configuration is obvious.
First, using the manage option of the feature and having navigated to a newly created API record, we identity the source service’s endpoint – up to the name of the controller (Values)
Then we express the wrapper endpoint’s form (to match)
On the “operations” screen (rather than the settings screen used above), we map interrupts offered by bank of the controller (known as “Values” in the case of our sample project):
Obviously, here one maps out the rest of the URI that the source endpoints expects.
The net result is that now one can use the “developers portal” to exercise the wrapped endpoint, using a diagnostic grade originator:
upon execution, not only does that screen update to show the Http response, both response headers and body, but since we are streaming the logs set to verbosely indicate what the web site in Azure websites is getting, we also see (from an earlier trial)
2014-05-16 22:30:55 NETMAGICRAP GET /api/Values/1 peter=here&subscription-key=03d7bee759b248309415d4a6216f7125&X-ARR-LOG-ID=a5083a20-5bdb-4cd4-97e4-9b0a2005056d 80 – 220.127.116.11 – – – netmagicrap.azurewebsites.net 200 0 0 464 639 15