How to stop same URL request for certain time

customer sends the request via apigee to backend  and he received as a bad request as a response, again he is sending without correcting response, would it be possible limit the same URL request at Apigee end for 30 seconds or 1 min. 

 

 

 

1 7 179
7 REPLIES 7

Not sure with little information..These are machine to machine interactions..You may save the backend hits by designing the external facing api proxy to be in maintenance mode with a kvm/app level flag(to turn for specific client) so that when backend is in maintenance mode you can enable it so that traffic wouldn't hit backend but you respond with 503. Not sure if it is a good thought on restricting the clients.

Think about it as it is not client issue but more of a backend..

Let us know what you think..

Thank you for your comment, here I dont want restrict the client by using some quota policy, just I want to stop for same kind of requests which is going to hit backend service. 

example: customer hitting this URL  (https://api.com/v3/trackings/RS17331AC) first time using some method, and customer received as a 400 bad request, and he/she did not checked/corrected at his end, again  he send same request, https://api.com/v3/trackings/RS17331AC,  in this scenario at Apigee end would it be possible to restrict/pause for some time?

Try re-reading the response :). Didn't meant quota policy.

Please could you explain how to re-reading the response or any article which I can refer, thank you! 

🙂 I meant read my earlier post. There is no automatic way to handle but design the api properly to meet your needs as described earlier.

I think the use-case you want is

  • when an app sends a request through Apigee and receives a "bad response", and then sends the same request again, Apigee should "limit" that request for some short time period, maybe 30-60 seconds.

We need to take care to define terms. What is a "bad response" and what do we mean by "limit that request"? 

It is possible for you to configure Apigee so that, for each 400 response (or 4xx) Apigee receives from the upstream system, it creates a cache entry, with some canonicalized representation of the request. This would be a SHA256 hash  on the combination of { URL, verb, query, headers, and content }. That would result in a unique value. You could configure Apigee to insert an element into the cache using THAT hash value as the cache key.  

Also configure Apigee so that on subsequent requests, it first checks the cache for the presence of the cache key.  If the cache element is present, Apigee can return a 429 or whatever you like, effectively telling the client "you are doing that too much".  Or, a more helpful response might be to just send back the original "bad response" including the same error code and so on. 

You could configure Apigee to do this.  But there is a caveat. The HTTP specs say that systems must not cache responses to POST requests.  In fact, don't cache for any non-idempotent request. Effectively that means you should not configure Apigee to behave in the way I described, except if the verb is GET or HEAD or OPTIONS. 

 

If that's ok for your case, then... 

  • In the Request flow: You can use AssignMessage to create a SHA256 hash. And then LookupCache using that value as the cache key. and then a Conditional RaiseFault if the cache key exists.
  • In the response flow, check for "bad response", and if the response is bad, use PopulateCache to create the cached item, for TTL = 30 seconds or 60 seconds, as you like. 

 

Thank you for the explanation, in my case it is post request, hence I dont want to try because of time constraint.