Guild Wars 2

Menomonia is only used for headings. IIRC the game uses Tahoma for all non-heading text.

McWolfy.5924:

Befor release anet promised mobile apps. I think its a great opportunity to rise the gaming experience. Chat, tp buy-sell, something SAB kind of game (or SAB itself) etc…
Now we only have event timers, tp price check and wiki
I realy want to log in from my mobile and enjoy a part of the game

That team hasn’t existed for years (I know, I was on it) it wasn’t going to ship anything unless we cut lots of stuff. The “Extended Experience” was doomed by a number of factors that aren’t worth going into, but I wouldn’t hold your breath for it to return in that form.

smiley.1438:

Thanks for the new floors.json, thats basically what i’ve proposed earlier

No problem! Thanks for all your suggestions, they were really useful.

Bugabuga.9721:

smiley.1438:

I’ve already proposed some json structure changes for the WvW APIs, so i’m gonna link these here for now – i’ll create some PR tomorrow.

matches.json https://gist.github.com/codemasher/8876102#file-matches3-json
match_details.json https://gist.github.com/codemasher/8894954
objectives.json https://gist.github.com/codemasher/bac2b4f87e7af128087e#file-gw2_objectives-json
(more to follow)

Thanks for the new floors.json, thats basically what i’ve proposed earlier

That makes me wonder — perhaps there should be “abbreviated” mode of endpoint? (and further compact it like this: https://gist.github.com/msmolev/c22210d53d10a4edd233 ) if volume of data transmitted is causing problems.

Unless there are amazing savings from doing so either on our end or the consumer’s end I’m not particularly interested in supporting two output styles for a particular endpoint. That just sounds like more code to write/debug/write tests for/maintain. I decided to investigate what the actual over-the-wire costs are for /v1/wvw/matches.json.

We gzip all responses for clients that support it (almost everyone) and the current /v1/wvw/matches.json output while verbose isn’t crazy. It’s 2.6KB uncompressed, but over the wire it’s only 380 bytes. The examples matches2.json starts out significantly smaller at ~700 bytes, and after gzip it’s down to ~325 bytes. So overall savings over the original file of 55 bytes.

I’m definitely not going to build & maintain two code paths to save 55 bytes over the wire, sorry.

Bugabuga.9721:

What will be the acceptable rate of requests for v2 API?

All of our API responses are cached for some period of time, so right now we aren’t enforcing any particular limits. It would be simple for us to rate limit endpoints in the future but we’re going into this in good faith that people won’t abuse it. Also our API frontends are pretty robust and giving them a good workout from time to time is nothing for us to panic about.

If you start noticing slowness/spotty responses though do let us know!

famfamfam.9137:

I’m interested in plans for versioning and compat.

In terms of making PR requests for format changes to existing endpoints, do you have any plans for how versioning will be handled to not-break backwards compatibility for existing clients? What are your existing thoughts on this, and do you think its possible/reasonable to do while also adding the huge list of functional things people want from the API?

Would it be best to make a PR proposal for the ability to specify the specific endpoint version you want to use per-request and changes to?

(Typed out a longer post but the forums swallowed it)

This is a longer-term question, we don’t have a complete answer yet. I’d like to move to that model after we’ve plumbed more of the data through, I just don’t know how we’d support that sanely within our codebase. I also haven’t seen any implementations of a model like that in an API I’ve used/investigated so I don’t know what sort of best practices we should follow.

I’d write up your proposal in a forum post or gist, it’s too long-term of an idea for a PR to be very useful right now. After we’ve gotten over the hump of exposing most of the useful/interesting data available I’d like to circle back around on a consistency pass that would potentially include a more flexible versioning story.

In terms of the current /v2 API, once we ship the API it won’t have fields deleted or renamed. We may add fields as more data becomes available.

Just a quick heads up that the release of the first beta authenticated API is being delayed until at least Monday of next week (2/23). This is due to a variety of not-seen-in-development configuration issues we’re slowly working our way through.

Once the APIs are available we’ll have a post announcing it and providing very basic getting started documentation. More complete docs should be on the wiki soon thereafter.

Sorry for the delay everybody, and thanks for bearing with us while work through this.

Sytherek.7689:

After reading this thread, I’m concerned about privacy.

Will the API allow anyone to investigate, say, anyone else’s backpack or storage?

Are we going to have to worry about gear-check apps?

No, you will have to give applications access to your data.

Divus.3175:

About historical tp data.

Either John Smith has his own server with all (I mean ALL) the data, or you have it somewhere in some form of historic tables. That’s just a wild guess.

John Smith has access to offline data querying stuff that isn’t suitable to expose via the API, sadly.

Also his secret is that he really gets most of his data from the fiber-optic cable in his brain that is wired directly to the DB servers in the datacenter. Limits his range of motion quite a bit, but at least his query latency is low.

/v2/skills is something Lawton’s been working on for a bit. Due to the way they’ve been organically constructed over time it’s a real hairy thing to make skill data be as regular as you’d want in an API. A proposal for that should be going up in the near future.

All authenticated APIs will be using OAuth2 and authenticating against https://account.guildwars2.com, yes.

dlonie.6547:

One API endpoint I’d like to see would provide access to historical trading post data — for example, to get the data to produce a graph similar to those on gw2spidy, gw2tp, etc.

Doing this currently requires constructing an external database and scraping the APIs regularly to populate it, and data from before the scrapes started is never accessible.

Before putting up a proposal for the endpoint parameters and response format, would something like this be possible? I.e., does ArenaNet store a detailed history of trading point data? Would the sheer amount of data that would potentially be pushed through their servers be problematic?

And thanks for starting this Pat — the APIs are one of the coolest things about this game for people like me

Lawton’s got a proposal for a user-specific TP transactions history endpoint he should be putting up as a PR. We need to get authenticated APIs up & stable before that API can become a reality though.

AFAIK we don’t track historical buy/sell data for items on the TP due to not having a need for it & it’s a lot of data. Something I can double-check though.

Welcome to the 2015 API CDI thread!

This is intended to be a slightly more structured location for us to discuss the various current & upcoming public APIs. In the past these threads were scattered all over the place (though the old suggestions sticky has some useful links) and I’d like to centralize things a bit. Especially as we start shipping the first of the authenticated APIs it feels like the right time to start this process.

So here’s how I’d like this to work.

• Discussion around more philosophical topics like future APIs, high-level details, etc will be handled in this thread.
• Actual API details (fields, formats, etc) will be discussed via pull requests against the api-cdi GitHub repository. These provide trackable history of changes as well as cleaner formatting options.
  • As an example, here’s my PR for moving /v2/floors under /v2/continents and cleaning up a bunch of the formatting. https://github.com/arenanet/api-cdi/pull/2
• Try to keep your posts relatively brief. Giant walls of text are hard to parse and discuss succinctly.
• Other CDI caveats and warnings apply. In the API forum we try to be more open about what we’re working on, but things change quickly and we try to spend more time working than posting.
• If you’re going to comment on a PR on the forums instead of on GitHub, quote the exact commit you want to discuss.

Example post commenting on a commit:

https://github.com/arenanet/api-cdi/commit/8ad156a98721b91954beeb5ee15793f29463bdea

I think that lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse commodo augue sit amet augue fermentum maximus. Suspendisse eu faucibus neque, sagittis bibendum arcu. Mauris hendrerit.

The most important thing to remember is that this whole idea is a work in progress! We’re open to modifying the process based on your feedback.

Current Proposals

• New format for /v2/floors, moved under /v2/continents
• Add /v2/account — basic scope only
• Initial pass at /v2/skills
• https://github.com/arenanet/api-cdi/pull/6

The fix for all of these issues is identical.

After some deep thoughts and a quick huddle over here we’re disabling /v2/floors, we’re not happy with how it looks and want to revisit it before anyone writes code to depend on it.

Aerodin.2795:

Pat Cavit.9234:

We’ll be switching the API frontends over to a brand-new version that is easier to maintain for us. This work also sets up the last bit of groundwork required to ship authenticated APIs, which we’re hoping to do next week.

Wow this is pretty huge news, and really exciting!! Just so it’s clear, is the plan/hope to have a thread to talk about future plans next week, or for the actual authenticated APIs to be available next week?

Both. The switchover in code happened this morning. Next week we’ll definitely kick off the CDI thread.

Not going to 100% promise that we will be able to enable the authenticated APIs then but it’s what we’re shooting for.

In the “managing expectations” department: The first authenticated API will be very simple. We’re starting with something simple and with low technical risk in case everything lights itself on fire.

smiley.1438:

Thanks Pat!

I wish the floors API would have been changed to be more useful. Seems like we still need to loop through the whole thing to find a single POI.

Also:
https://forum-en.gw2archive.eu/forum/community/api/API-Suggestion-Maps-API/first#post2261295
https://forum-en.gw2archive.eu/forum/community/api/It-has-become-silent-in-here/2501399

The floors API hasn’t gotten much love, as you can see. I’m open to changing the format because it’s straightforward for us to do. So far we’ve been focused on porting the previous API code onto the new backend and prepping for authenticated APIs.

What we should change the format to will be something we should discuss as part of the upcoming API discussion thread. We can use the posts you linked as a starting point for that discussion.

The switchover has completed. We’re not quite done with the maintenance, next we’ll be changing the DNS record for api.guildwars2.com to use latency-based routing to send folks to either the US or EU. Previously all API traffic was served from our US datacenter.

We’ve also enabled most of the rest of the /v2 APIs that were still disabled, though a few are still hanging out pending a more complete review.

The newly-enabled /v2 APIs are:

• /v2/build
• /v2/colors
• /v2/continents
• /v2/files
• /v2/floors
• /v2/maps
• /v2/skins

We’re going to be doing some behind-the-scenes maintenance in a few minutes, in theory there should be few/no user facing changes but you never know. Tests are looking good.

We’ll be switching the API frontends over to a brand-new version that is easier to maintain for us. This work also sets up the last bit of groundwork required to ship authenticated APIs, which we’re hoping to do next week.

It’s not ready, but we’re working on a post with more details about our near & mid-term hopes and dreams for the API. We’ll be looking for feedback on the authenticated APIs as well as trying to give some sense of what we’re planning to ship going forward. The intent is to model it along the lines of the CDI threads you see for game design.

Clearing your browser cache won’t help, GW2 has its own browser built-in. Try this instead.

1. Close GW2
2. Open “My Computer” or “Computer” (depending on your version of Windows)
3. Type “%TEMP%” (without the quotes) into the address bar.
4. Delete all folders starting with “gw2cache-”
5. Open GW2

Here’s some example folder names to help you identify the right folders. They will have slightly different names on your machines.

gw2cache-{16611E0B-2F1D-1A36-081E-61161D2F361A}
gw2cache-{16611E0B-472E-1A67-081E-61162E47671A}
gw2cache-{16611E0B-539F-19C2-081E-61169F53C219}
gw2cache-{16611E0B-53F4-1988-081E-6116F4538819}
gw2cache-{16611E0B-5459-19A5-081E-61165954A519}
gw2cache-{16611E0B-B678-199A-081E-611678B69A19}

Merus.9475:

Those complications don’t happen to involve any of the issues talked about in this blog post, do they?

I understand that Steam is decommissioning its OAuth2 implementation, but then who know why Valve does anything.

No, we don’t use any of the more wild things lurking at the edges of OAuth2, fortunately.

We’re going to do some experiments around searching to see if we can’t start offering richer search APIs in the future. Can’t promise anything though.

OAuth2 is still a thing we’re working on. There’s been some complications but it is still happening.

It’s on our list, I don’t have an ETA for you.

This is unlikely, the whole point is to log in to the actual game. Sorry!

StevenL.3761:

Does that imply that we should get faster loading times now than back when the updated TP was launched?

Yeah, once the UI has loaded it’s noticeably faster searching/switching between sections/etc. We can avoid a lot of the TCP overhead of HTTP by re-using the existing game connection.

See here: https://forum-en.gw2archive.eu/forum/community/api/Guide-to-the-Black-Lion-Trading-Co-API/page/2#post4612198

Sure, I see how what I said is confusing. I’ll elaborate.

As part of the rewrite we also set it up so that the Commerce apps could go over the existing game connection instead of making HTTP requests. It’s more efficient (there’s no per-host limit on the number of requests we can make) and avoids some of the overhead. Until we could do some more testing of that on live we had a simple HTTP proxy for requests.

Once we cut over completely to the game connection the HTTP proxy was automatically disabled. It’s been deleted entirely in dev so it will start 404ing before too long.

ameerpostalman.8975:

Looks like this doesnt work anymore?

TP was completely rewritten and all these endpoints are gone, yes.

Pat Cavit.9234:

You should really use the Official API though, we provide zero guarantees that we won’t break everything out from underneath you if you’re going against the TP directly.

We didn’t go out of our way to remove them, we literally threw out all of that code and started from scratch. The entire Trading Post frontend was rewritten w/ no code brought forward from the old TP because it frankly wasn’t all that good. I say that as the person that wrote most of that code, so I’m not throwing anyone under the bus in case anyone was wondering.

And for the record I’m absolutely the person responsible for that decision. Vent away if you have to.

Risingashes.8694:

Okay, thanks.

Would have been nice if the functionality that worked wasn’t specifically disabled before the API caught up, but I’m assuming that’s outside your purview.

Querying the TP via the web endpoints was never a supported option, and we made no guarantees that we wouldn’t remove it.

We don’t currently provide a search endpoint, sorry. It’s something we’re looking at but has implications for the backing services that we need to work through.

We haven’t forgotten about this request. Don’t have anything more to report right now, unfortunately.

The underlying servers that provide game data had a bogus deploy script and weren’t able to get updated content.

Should be fixed now.

The listings have been removed from the TP (Notice how there’s no buys or sells for https://api.guildwars2.com/v2/commerce/listings/29974) but they weren’t re-marked as undiscovered when we cleared them out.

Seems like our fix wasn’t complete, I’ll bug somebody about that.

https://tradingpost-dfw-live.ncplatform.net
https://tradingpost-fra-live.ncplatform.net

You should really use the Official API though, we provide zero guarantees that we won’t break everything out from underneath you if you’re going against the TP directly.

That’s not how it is currently implemented, and changing core tenants of the commerce systems solely to tweak API behavior is incredibly unlikely to happen.

If an item doesn’t exist in the commerce systems, then it has never had a sell order placed for it.

This is to prevent people from placing buy orders for items before there are any being sold and thus influencing markets that don’t exist yet.

We aren’t going to change this behavior right now, I’m sorry you find it confusing but it’s not something we can easily workaround given that /v2/items and /v2/commerce/prices are going against different systems that have different ideas on what valid items are.

I’m not comfortable with special casing the commerce APIs right now, so they will continue to return the standard error.

poke.3712:

Documentation on the wiki: recipes, recipes/search

poke is my hero

poke.3712:

Documentation on the wiki

poke is my hero

Remfin.4892:

If you’re following the link from this forum, it looks like their exit page escapes ampersands in URLs no matter what you do. Paste the URL directly into your browser and you’ll see the 300 page size blows up: "{"text":“page_size out of range. Use page_size values 1 – 200.”}"

Yup, forums has a link encoding bug and is breaking multiple query params. I’ve verified w/ every link posted so far (after fixing) that all the headers are correct.

https://api.guildwars2.com/v2/worlds
https://api.guildwars2.com/v2/worlds?page=0
https://api.guildwars2.com/v2/worlds/1005
https://api.guildwars2.com/v2/worlds?page=0&lang=fr

etc etc.

Yeah, every /v1 API had its CORS headers go missing. They should all be back in place now.

We’ll take a look, seems like something got missed in the tests.

DarkSpirit.7046:

Pat Cavit.9234:

Hey folks, we’ve just enabled /v2/items. Documentation isn’t quite ready yet but I’ll be talking to poke and we’ll go from there.

Querying it is identical to the other /v2 APIs.

https://api.guildwars2.com/v2/items/12138
https://api.guildwars2.com/v2/items?page=0
https://api.guildwars2.com/v2/items?page=1&page_size=200
https://api.guildwars2.com/v2/items?ids=12138,57

By the way, your page_size parameter seems to be ignored. X-Page-Size always return 50 when specifying pages.

RedBot and my browser agree that it’s fine.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Content-Language: en
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Content-Type-Options: nosniff
Link: </v2/items?page=0&page_size=200>; rel=previous,
</v2/items?page=2&page_size=200>; rel=next,
</v2/items?page=1&page_size=200>; rel=self,
</v2/items?page=0&page_size=200>; rel=first,
</v2/items?page=195&page_size=200>; rel=last
X-Page-Total: 196
X-Page-Size: 200
X-Result-Total: 39108
X-Result-Count: 200
Access-Control-Allow-Origin: *
Date: Fri, 24 Oct 2014 18:15:06 GMT
Content-Length: 8706

Looks right to me.

Documentation isn’t ready yet, but here’s some example links to get you started.

https://api.guildwars2.com/v2/recipes/2869
https://api.guildwars2.com/v2/recipes/9716

https://api.guildwars2.com/v2/recipes/search?input=12138
https://api.guildwars2.com/v2/recipes/search?output=45656

Should be fixed after the next patch.

We’re looking at this now, sorry for the hassle.

API talks to some of the same back end servers, but the public API frontend you hit is totally separate from game systems.

I’m not opposed to this, but it’s not high on our priority list for the APIs at the moment.

StevenL.3761:

xD sorry. What would be a more democratic delay between each request?

No no, I’m thrilled that you can grab it that fast.

StevenL.3761:

Hey, is anyone else running into HTTP “speed bumps”? If I send too many requests, I start seeing HTTP 502 (Gateway Timeout) and I have to wait a minute or two before I can send new requests. Just wondering if this is a technical limitation, or if we’re being throttled.

edit

Must have been a network congestion thing. It doesn’t happen now, even though I tweaked my code to send even more requests. My best record is a full download of the items database for all languages in just under 32 seconds. I’m impressed by how well the API responds to that many concurrent requests.

:)