Guild Wars 2

Let’s say I wanted to make a watcher for a select list of events.
Naturally, I’ll be querying /v1/events, possibly specifying a world_id.

I see how to limit the output to one event, but it’s not clear if you support having the results limited to a set of event_ids, rather than dumping all of them. Sending one query per event is not the right answer (slow and expensive). So in the meantime I’m just gonna dump all the events, and filter client side.

However, if it would take any pressure off your severs for me to be more specific in what I want, then let us know what the syntax is. Thanks!

Nope. I’m used to dealing with fractional gigabyte strings.

I would love to see the ability to filter multiple items, specifically in the event API by event_id.

My use case is as such: I am tracking several meta-events, and as such am looking for information on every event in those meta-events at the same time. My options are:

1.) Pull all events and filter client-side (quite a bit of processing)
2.) Pull single events, all at once (60+ requests to arenanet simultaneously)
3.) Pull events by map (combo of the previous)

It would be nice to just let the server filter, since I’m assuming it’s using a DB backend with indexing so filtering is much easier on your end.

While it would be a lot easier for you, I suspect that allowing for a large amount of filtering server side would actually be more expensive for their system than just doing a full dump.

Since we’re talking about a central resource that’s common to the entire community, it is very likely that your option #1 generates the least load on the servers.

This is more or less what I was asking in the OP, and I interpret Cliff’s response as validation of my suspicions.

I’m making the assumption that their various IDs are indexed in a database somewhere, and that the data being returned is essentially the result of a query to that database. If that is the case, then adding multiple keys to the where clause of such a search is trivial and should cause a negligible performance hit.

This is of course my assumption. There may be more processing involved and that might be an issue.

I interpreted Cliff’s response as just that the current APIs don’t support it and that they are fine with you pulling down mass amounts of data you’re going to throw away, but also that if we would prefer to have more filtering support server side, to let him know (and then a smiley face).

Either way, I see several use-cases where multiple filtering would be useful and was just posting a suggestion for efficiency’s sake. 1.) and 3.) involve a ton of data that will be thrown away client side, and 3.) involves excessive server requests. It would be nice to just be able to make 1 request to their server and get only the data needed.