WvW matchID resolution
DistantStatic.6098:
I’m in the process of making a mobile app for WvW, but to resolve the matchID for a specific world feels like I’m jumping through hoops. No matter what solution I’m coming up with it results in me having to receive all the WvW match data and searching through it all to find the one I’m looking for.
I’ve come to terms with having to make a hashtable for the world id’s to reduce network use, but it would probably be more beneficial on both ends if we could get the current WvW match id to be returned inside of the worlds endpoint.
These don’t get changed around all that often (once a week) and it saves you guys bandwidth and cycle time for every time someone requests the information for some cycle time every friday on the API end.
Also, if I’m missing something (I’m sometimes blind and very much human) and there’s a better way of doing this, I’d appreciate if you share it with me
.
Sol Solus.3167:
If you are able to use regular expressions or something similar, you can use the regex I use in my WvW app to resolve the match ID from a world ID in one pass: (Sample ID is for Tarnished Coast, 1017)
(?sU)(?=\{[^}]*:1017).*:"(.*)"
It finds the world ID then backtracks to the match ID using the curly brackets as a boundary.
DistantStatic.6098:
That certainly is an alternative to a for each, but still requires pulling all the extra bulk that comes along with requesting “all”. The less network data used the better.
Edit: The whole API process is already rather heavy on a galaxy S4 with 4GLTE I can only imagine on a cheaper chinese phone with a worse network connection :S
Sol Solus.3167:
v1/wvw/matches is 2.6 kb. A single request of v1/wvw/match_details.json is about 3 kb, and v2/wvw/matches is 3 times that. If you are making anything resembling a live map, the bandwidth usage imposed by getting match ID (which you can cache for the rest of the week) is the least of your worries.
DistantStatic.6098:
Doesn’t mean we can’t cut the fat. It’s not like the API is broken or anything like that, just offering a suggestion that would make this a bit lighter
Lawton Campbell.8517:
There’s probably going to be a /v2/wvw/overview (or maybe /v2/wvw/worlds) at some point that provides this data, if only because I have the same issue when debugging stuff locally :c
Tanis.5134:
My current strategy is to use the v1 matches endpoint to get the world ID → match ID mapping. That’s a relatively small dataset, and I can cache it week-to-week.
Lawton mentioned in the v2 matches PR that he is planning on adding something else for a v2 world ID → match ID mapping.
I’m also planning on submitting a PR to add a world ID parameter to the /v2/wvw/matches endpoint once the existing work has been merged in. This would allow querying for a match by the world ID instead of by the match ID, eliminating the extra step of mapping a world to a match.
fooey.5824:
I have a little site that I use to power gw2w2w.com that has a few extra endpoints to do what you’re looking for. Feel free to use it, though no guarantees on uptime, or check the source and run your own (node.js).
http://state.gw2w2w.com/world/1009
http://state.gw2w2w.com/world/fort-aspenwood
http://state.gw2w2w.com/matches/worlds
https://github.com/fooey/gw2w2w-state
DistantStatic.6098:
Awesome thanks all.