I have an Azure API Management API for which I am mocking a particular operation.
I have set up the mock to simulate the back-end service response (including urls in the response that look like they are emerging from the back-end service).
I have found that none of my outbound policies, including the redirect-content-urls policy, are getting applied for this mocked response so the urls being returned to the consumer are incorrect.
Now I know I can work around this in the mock itself, but what I would like is to be able to have all of my outbound policies applied to the mock response so that I can fully test my API without needing the back-end in place.
Is there a way around this other than by stubbing the back-end service?
The mock response policy will pick up the matching response from the responses that are configured for the api. If no response is defined then an empty response will be returned for the status code.
As for the execution, as soon as the policy is encountered the policy execution is interrupted and the service will return the response based on your mock policy. Consider following scenarios where the mock-response policy is placed and its effect
Inbound : In this as soon as the mock response policy is encountered, execution is halted and the response is returned. You cant really apply the content-redirect-url property here. It will throw an exception in execution of the policy engine
Outbound: For the mock response to work in this section, you will have to have a backend service where you will send the request(which is not possible as there is no backend!) post which the outbound policies will be applied.
So there is no direct way to implement the out bound polices when the mock response is defined in inbound. Best bet is to implemented the masked redirect content url in the mock response sample itself.
Related
I want to serve a request by APIM policy only, is it required to have API and operation for the same ?
for example
https://myapim/myapi/myoperation
I will serve this request from policy itself by calling few external APIs, do i need to create myapi API and myopration as blank operation ? or is there anyway to handle this ? currently i am getting 404 from APIM before reaching to policy code.
When you create api in APIM, it will ask you to input your backend url like below screenshot.
And then when you create operation, if you input /myoperation/ into the "URL" box like below:
It will request https://your-backend-url/myoperation in the backend, but your backend url is https://your-backend-url. So you may get 404 error. To solve this problem, you can just input / into the "URL" box when you create operation.
I had to create a dummy operation in my API by this my policy is getting executed and serving the request.
All the incoming request to api management will have a token in a header, before backend service is hit token has to be verified. To verify token a GET tokenVallidationApi is to be hit and the response will tell us whether the token is valid or not. If the response exists for token validation , we have to take out few entries from response and enrich the body/header to hit the backend api. I am very new to api management tool and just figuring out how can we achieve this with azure api management?
This is possible. You would have to implement your policies like something below
1. Validate Token
For this, you would first call the validation endpoint using send-request. You could also implement caching using value caching policies for multiple requests.
The doc also highlights how you can extract value from the response body.
2. Transform Body & Headers
For headers, you would use the set-header policy and for the body, you would use the set-body policy.
We have a gRPC server written in golang. For one of the RPCs, we request data from the Google Maps gRPC API. Once we receive a response from the Google Maps RPC, we do some calculations and return a response to the enclosing RPC (defined by our server).
Naturally, we receive a Context object when the RPC is called on our server.
My question is: Should we pass this same Context object to the Google Maps RPC? Or, should we instead create a new Context object (using context.Background()), and then pass this to the Google Maps API?
The context you received contains the cancellation and timeout, so it would be good to use the same context to make the new RPC. Otherwise you need to manually pass these signals.
A side on the metadata, metadata in the received context will not be automatically forwarded to the new RPC, see:
https://github.com/grpc/grpc-go/issues/1148
https://github.com/grpc/grpc-go/pull/1157
As far as i have figured, 1 context is valid for the life cycle of 1 and only 1 rpc.
So as soon as we realize that we are about to make a whole different rpc call, we should make a new context.
However, The metadata of the new context may be inspired by the metadata of the current context.
An RPC here may be considered analogous to a single activity/service/broadcast in android.
we have an production issue where the order is submitted twice. Currently we have an API for order and we are exposing this to client using API management and in these we have policies for URL mapping for customer facing to actual .
Now , our actual API got 2 request so we thought customer submitted twice but they have confirmed that they have not submitted twice , so either there is issue with API management which fired 2 request.
How can i Identify the request received by the API management ?
Is there any chance that API management will fire the request twice ?
Appreciate any pointers
The only way to fire request twice in APIM would be by the means of Retry policy or manually using SendRequest. Otherwise it should be a client calling your API two times. Each request in APIM get it's own unique id accessible in policies as context.RequestId, this is the main way to track and identify them. But these ids are produced inside APIM itself thus are useful only if you're tracking a call from APIM and into backend.
Your best option now is to try to identify requests by client ip, method, uri, and time frame. APIM allows you to grab logs for certain periods of time (better if kept short) in JSON or CSV with data I mentioned above. To do that look into byRequest report (https://learn.microsoft.com/en-us/rest/api/apimanagement/reports#ReportByRequest), grab JSON/CSV and try to identify calls of interest,
For future you could look into onboarding your service to azure monitor (https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-use-azure-monitor) or log analytics those provide easier way to traverse logs.
Currently writing some documentation. Just wondering if we are using the terminology correctly.
We have an AJAX script that calls a service using a HTTP GET that returns JSON.
Would you call the service a REST service or a JSON service?
Using HTTP does not mean you're automatically following the REST architectural style. If you don't know what REST is, you're pretty much guaranteed to not be doing it. Call it "a web service that returns JSON" instead.
I'd call it a REST service which returns JSON.
EDIT
6 years on and what was I thinking! It's a web service which returns Json, as suggested in other answers. It may be RESTful, it may not.
A client calling a service using an HTTP GET would not constitute a RESTful architecture. The following elements should exist for a service that has a RESTful architecture.
HTTP - used as an application protocol, not a transport protocol
URI tunneling
Hypermedia
So, in your scenario, based on the given information, your service can be classified as a regular service with JSON hypermedia or content type. It is definetly not a REST architecture.
Here are some additional information:http://goo.gl/32gLK