Guild Wars 2

Hi, I have made a android app to use the api. The app can be found in google play by searching for “GW2 Event Timer”. I would like to attempt to reduce the data used to fetch the API.

If I use the following url
https://api.guildwars2.com/v1/events.json?world_id=1004
The data is around 154KB
I notice that in the API documentation https://forum-en.gw2archive.eu/forum/community/api/API-Documentation/first#post2028044, it is possible to use optional parameters like event_id.

If i use the url
https://api.guildwars2.com/v1/events.json?event_id=9AA133DC-F630-4A0E-BB5D-EE34A2B306C2 (The event_id here is for one of the world boss)
The data is around 5KB. Although it seems to be a huge reduction but the issue is that if I were to fetch 30+ event_id, the data used will be over 154KB.

Thus am I able to do something like
https://api.guildwars2.com/v1/events.json?world_id=1004,event_id=9AA133DC-F630-4A0E-BB5D-EE34A2B306C2
??
Maybe the format of the algorithm or the way I’m doing it is wrong but this url doesn’t return the results i’m expecting. Anyone knows or maybe can the developers advise if it is possible?

Basically I intend to construct a url made up of the following
https://api.guildwars2.com/v1/events.json?world_id=1004
followed by event_id=(Insert many event_ids here)

Query string parameters are seperated by & and are AND-ed to filter your results.

What you want is probably (only show a single event from a single world):
https://api.guildwars2.com/v1/events.json?world_id=1004&event_id=9AA133DC-F630-4A0E-BB5D-EE34A2B306C2

Currently, you can’t supply multiple IDs of any type to get the status of a list of events from the API at once.

Unfortunately, they don’t support something like event_ids=1,2,3. Instead, you’ll have to query each event individually. Depending on how many events you’re tracking and how often, individual queries will most likely be more efficient. Unfortunately though, since the responses are quite small, the http headers end up being just as big as the response data, meaning if they did support something like multiple ids, you could cut the data usage in half.

If you’re trying to request as little data as possible, the most efficient method would be to make your own API that collects data, which you then request from. By doing this, you can turn 100 or so calls at a cost of ~15KB down to 1 call at a cost of a few hundred bytes.

Hi, thanks for the response, I think both of you made good points. I do not know exactly how much data is required for the HTTP calls but using the method by Think, the url now returns 1 line which is pretty good. But I agree with Healix that the HTTP calls will likely buff up the data used which makes this concept not feasible due to the many calls required.

As for making my own API, etc, I’m afraid that is also not feasible for my app as I do not have a server to pull and perform this consolidation of data. If I were to perform it on the user’s device (Android App), it will still defeat the objective of trying to reduce data usage.

But thanks very much for the information!

If you’re going to use the full lists, be sure to use gzip compression (“Accept-Encoding: gzip” in the request header). Depending on how/what you’re using to request the data, you may already be doing this. It’ll reduce that 150 KB response down to about 40 KB.

When doing small requests however, disable compression. It’ll only bloat the response by a few bytes + the extra headers.

Ok thanks for the idea, I’ll have to research what gzip compression (“Accept-Encoding: gzip” in the request header) will mean in android programming.

ScArZ.4953:

Ok thanks for the idea, I’ll have to research what gzip compression (“Accept-Encoding: gzip” in the request header) will mean in android programming.

Maybe this would help:

http://stackoverflow.com/questions/1573391/android-http-communication-should-use-accept-encoding-gzip

Hi DarkSpirit, thanks for the information. After researching, I managed to reduce the receive data by almost 4 times. The additional header info only increased the transmit data by around 16%