How to retrieve X-RateLimit params through the API?

[baszero]

Hi,

is there any example of how to process the result of a send request?

e.g. if you have
MessageSent[] result = smartEmail.send(smartEmailRequest);
how should you process the results?

I'm actually looking for a recommended solution on how to follow the rate limit which is returned by Campaign Monitor: https://www.campaignmonitor.com/api/getting-started/#rate_limiting

[baszero]

I noticed that the Rate Limits are provided in the HttpResponse as HTTP Header Parameters:

As of Campaign Monitor support, the Rate Limit parameters are provided in EACH response regardless of the status code, e.g.:

HTTP/1.1 429 Forbidden
Date: Tue, 20 Jan 2014 14:50:41 GMT
Status: 429 Forbidden
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 348
{
    "Code": 429,
    "Message": "Rate limit exceeded"
}

So my question is: How can I access the response object in order to parse the HTTP Header parameters and finde these values?

[shahidt]

I am looking for a solution to this problem as well. Any luck?

[baszero]

I was in contact with campaign monitor, they say that they don't provide examples.
However I think you have to program it yourself, e.g. like this:

Enumeration headerNames = request.getHeaderNames();
while (headerNames.hasMoreElements()) {
	String key = (String) headerNames.nextElement();
	String value = request.getHeader(key);
	map.put(key, value);
}
// and now check map for the X-Rate* keys

[shahidt]

Would I need to put that in the wrapper around where the requests are made? I was hoping to not touch the original set of wrapper codes at all.

[baszero]

in your own code, you call the API, and you parse the response, if possible. I didn't try it, it's just what I'd try first.

[richardbremner]

Hi. Whilst I have not tested this assumption, if you exceed the rate limit you should get a 429 response (as @baszero stated), this non 200 response should cause a CreateSendException to be raised containing the 429 code. You could then read this, and back off. It's not an ideal solution, but it does get you some of the way there.

The Jersey client library doesn't make it easy to expose the response headers like you need, it looks like it would require some refactoring of the wrapper.