Hi,
would it be possible to enable HTTP head requests(obviously, never a return body), to get the If-Modified-Since?
Or alternatively a seperate endpoint, like before for this.
The reason I am asking is because my application is running on AWS Lambda functions. And it would cost more(due to increased RAM costs), to send API requests to that endpoint.
I am getting 500 Malormed request, when I try to do this. I have tested it on other websites, and it works just fine.
Edit: Meant head request not header.
Do you mean HTTP HEAD requests ?
If-Modified-Since is a request header not a response header.
The whole point for the If-Modified-Since header is to only receive a body if the content was modified since a valid http date.
If the content hasn’t changed since that date you receive a 304 Not Modified response (no body) instead of a 200 Ok.
For more information:
The If-Modified-Since header is already working with the endpoint so is Last-Modified for responses.
Correct, I ment HEAD request 
I was hoping to avoid using GET to check if updates are available. In case of the API not being consistent in the times when data is updated(or when the API is down), it would be cheaper to have one lambda function that checks if there is an update and then pass it off to another if there is(with exponential back-off or something).
Or is there a high probability of the update frequency not changing now, or?
I think using If-Modified-Since is pretty safe to use. You can save the Last-Modified of each realm when you get a response and check periodically using that timestamp in your request header.
If they implement a HEAD endpoint you’ll be dealing with almost the same resource cost as a you would in a non modified requests (just the headers), and if you have to perform a new GET request to fetch the body when the Last-Modified have changed you would end up receiving the headers again.
The only way you would have a “surprise” is if they change the update rate of those dump files, but you can avoid that by only testing for changes on a fixed schedule.
That part I agree you should have a sepearate function to check at least one request for each region, but your enemy in this scenario is not really the response payload, it is the timeout. You want your lambda function to return as fast as possible, so I would fetch a simpler endpoint (realm index perhaps) and set a low timeout, just to check for a timeout or 5xx.
When the lambda times out due to lack of memory, the function actually just hangs so it won’t be able to do anything else.
With AWS lambda(And Azure functions I think), the price is affected by the amount of available memory etc. But I guess that it won’t hurt too much, moving both the check and the fetch into one Lambda function.
Just kind of liked how that part of the old API at least.
You want to send a HEAD request to skip the response body, but you can’t do that. Instead, send a GET request which will never return a body: one that was modified since the future. You’ll always get a 304 Not Modified, and get the Last-Modified response header.
GET /data/wow/connected-realm/5/auctions?namespace=dynamic-us&locale=en_US&access_token=ZZZZZ HTTP/1.1
Host: us.api.blizzard.com
If-Modified-Since: Sat, 01 Jan 2050 00:00:00 GMT
HTTP/1.1 304 Not Modified
Battlenet-Schema-Revision: 5
Date: Mon, 02 Mar 2020 18:19:52 GMT
Server: Apache-Coyote/1.1
Last-Modified: Mon, 2 Mar 2020 18:06:26 GMT
Battlenet-Namespace: dynamic-us
Battlenet-Schema: auctions
content-length: 0
6 Likes
I did not think of that. Fantastic, thanks!