Guild Wars 2

Cool idea, can’t commit to it right now.

Or just using pagination + the Link headers we return (see https://tools.ietf.org/html/rfc5988 for a description)

https://help.guildwars2.com is the real support site. You can click the padlock icon in the URL bar & open up the certificate details to verify.

As for the wonky favicon, I dunno. I didn’t have much to do w/ the set up of that site.

There was a bug around launch that allowed below-vendor buy orders on items. It was fixed but not before a bunch of automated buy orders for nonsense were put in.

We were discussing ways to clean this up relatively recently and think we have a plan, though the complexity of the operation means we’re not going to rush to do it.

StevenL.3761:

I think this behavior is caused by a setting in the Request Filtering module (http://www.iis.net/configreference/system.webserver/security/requestfiltering). The article perfectly matches the behavior that I’m seeing.

When request filtering blocks an HTTP request, IIS 7 will return an HTTP 404 error to the client and log the HTTP status with a unique substatus that identifies the reason that the request was denied.

So, to disable the filter:

• Open IIS Manager and connect to the gateway server that routes the requests
• Click the root node of the server in the “Connections” panel
• Double click “Request filtering” in the “Features View” panel
• Click “Edit Feature Settings…” in the “Actions” panel
• Change the maximum URL and query string length to 4294967295 (max), or something more sensible than 2048/4096

The defaults are sensible and we aren’t going to change them for now. Don’t request 500 IDs at once, especially since the max we’ll return to you is 200.

StevenL.3761:

I’m not sure if this is even worth looking at, but there’s still that bug where IIS crashes with a text/html response when the parameter list gets too big. Probably because IIS/ARR and the private API do not agree on the maximum URL length.

Example: http://pastebin.com/nXSR8kSb

Garbage in, garbage out!

Not a lot we can easily do about that right now.

StevenL.3761:

I can’t check on my phone, but I don’t believe that ID 1 returns an error code. Just HTTP 200 and a garbage value.

Clearly still too early, my brain flipped your “OK” and “Not OK” values. Sorry!

poke.3712:

I looked at all items, and ended up with the documentation. Hope it helps

This is so great. Thanks poke!

Dr Ishmael.9685:

https://forum-en.gw2archive.eu/forum/community/api/Return-proper-error-codes/first#post2961806

API v1 was originally using non-informative HTTP codes, so I wrote my module to look at the returned JSON instead. I never bothered updating it after Stefan’s changes because my method “just worked.” I guess I’ll have to update now.

I can’t possible disagree more with your proposal in that thread, sorry. Errors should always return the most-appropriate HTTP error status code in the response. Extra information kittentainly come back in the response body (and we need to do better standardizing those) but the status code should always be the very first thing any consumer checks once a response is received.

StevenL.3761:

Pat Cavit.9234:

StevenL.3761:

/v2/commerce/listings returns literal “null” strings when a bulk request specifies non-existent or account-bound item identifiers.

https://api.guildwars2.com/v2/commerce/listings?ids=-2,-3,6,24

You might have to refresh the page a couple of times to see it.

I tried two different serialization engines, and both fail to correctly recognize these values as null.

We’re taking a look at this and have a plan for how to fix. That’s a fun one, good catch!

It’s better now, but there are still some inconsistencies that make my code crash.

Right now, the listings service returns garbage values instead of an error for some identifiers:

OK: https://api.guildwars2.com/v2/commerce/listings/0
Not OK: https://api.guildwars2.com/v2/commerce/listings/1

Same story for the prices service.

OK: https://api.guildwars2.com/v2/commerce/prices/0
Not OK: https://api.guildwars2.com/v2/commerce/prices/1

We can look at standardizing those some, but both are correctly returning a 400 bad request. It gets exciting since the API is a layer on top of many backend services and those don’t all agree on how to respond to things.

That said, you should always determine if the request was an error by inspecting the HTTP status code & not the contents of the response.

Yeah, sorry about that. We’re working on a plan to clean up the Commerce listings database but obviously we’re being very careful abut it because, y’know, Commerce DB.

Why aren’t you using the HTTP response code to check for errors?

Those errors are coming from different levels/servers, so it’s not super surprising they’re different. We can take a look at standardizing but you should always use the HTTP status code first and foremost.

https://api.guildwars2.com/v2/items/56

default_skin is now a number, like it should’ve been all along

https://api.guildwars2.com/v2/items/21092

UpgradeComponents now have a proper details object, like they should’ve had all along.

Sorry about the bugs! We have lots of items, some are weird XD

poke.3712:

The full documentation is now available, including all edge cases and oddities currently in the API.

This is awesome, thanks so much poke! We’ll get the upgrade_components & default_skin bugs sorted pretty soon here.

The Ice Mage.4879:

What is it then? Something developed in-house?

Yes, it’s a simple reverse proxy that knows about our server infrastructure so it requires almost zero configuration.

It’s pretty great.

smiley.1438:

36 minutes on my connection for a full update (4 languages) – while downloading chunks of just 50. I guess it’ll be done in a few minutes on darthmaim’s server then (gw2treasures.de). I ran a v1 update before just for testing and it was like i predicted ~ 3 hours.

?page_size=200 is very useful here.

Given the recent changes to the structure of the APIs we’re unlikely to offer XML going forward. It’s just not easy to do and I’m having a hard time finding any environment that can’t consume JSON.

Kasoki.7013:

I’ve made this naive approach exactly to show how inconvenient it is to retrieve certain items at the moment.

The current API design somewhat encourages lots of API calls which are obviously bad both for Arena.NET and for the user. An item search API or an interface like your item_names.json would be quite a pleasure.

I’m currently caching all items in a similar structure as your item_names.json but to build this I still need to download every single item once. This is a pretty huge amount of data just to make a simple search: ~38k items = ~38k HTTP calls…

38000 items / 200 per page using pagination = 190 requests.

But yes, I agree a search API would be nice!

poke.3712:

Documentation is now available on the wiki. For now, I’ll refer you to the v1 documentation for the type-specific properties. I’ll update that as soon as I verified whether the format changed for anything in v2.

Thanks a ton poke, sorry about the surprise launch. trying to get /v2 APIs out as fast as we finish cleaning them/making them scale, so this probably isn’t the last surprise :-\

StevenL.3761:

I’m PRETTY sure this looks wrong: https://api.guildwars2.com/v2/items/21092

Shouldn’t that ‘upgrade_component’ property instead be a ‘details’ property?

Hmm, looks like our tests weren’t checking for that. Probably just a mapping update, but we’ll take a look.

poke.3712:

Pat Cavit.9234:

Yup, we make a bunch of async requests for the data and simply assemble it in the order it returns.

Is that order consistent enough for paging though? I.e. when using the paging mechanism, can I be sure that I get every object at some point, or is it possible that some will be missed because the order for one page ended up being different than the other?

We start w/ the complete list of IDs for paging, so yes. Each individual page may not have a guaranteed order, but it does have a guaranteed set of IDs that will be returned.

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

What’s wrong with Tacos? They’re delicious!

Also our TacoProxy is unaffiliated with tacoproxy.com, for the record.

Quickbeam.2481:

When opening TP and doing a search of lets say everything I get a very limited list of items with a message saying I’ve reached my max results. Now, if I enter into EG mode I get a list that I believe it is safe to assume is about 5x as long.

Sorry if I wasn’t clear but I wasn’t posting about changes to searching/browsing behavior when buying. I was specifically talking about “My Transactions” which now returns up to 1000 current buy listings and 1000 current sell listings without needing to enable EG mode.

I’ve used https://code.google.com/p/rolling-curl/ in the past with success, looks like it might be a similar implementation.

There’s something weird going on with the WvW maps, the WvW team is tracking it down. The issue they’ve been discussing sounds suspiciously like something that would cause the behavior you’re seeing.

Quickbeam.2481:

From what I’m seeing to view the extra listings enter into the aforementioned alternate ‘I am Evon Gnashblade’ mode.

Seeing all your listings doesn’t require EG mode.

Ensign.2189:

Noticed that the default quantity when selling is now however many you have and not 1. Great job, keep it up!

Thanks, I knew there was another change I forgot to mention.

Buying was accidentally switched to default to placing orders. This has been fixed.

We’ve also changed it so that the price per unit will now automatically increase as you increase your quantity.

As a temporary measure until we’ve bumped the number of current transactions loaded from 400 (200 buy, 200 sell) to 2000.

We’re still working on a longer-term fix, as we’re aware that this doesn’t solve the problems for users with a very high number of transactions.

I’ll think about it, but it’s not going to be a high priority compared to getting the rest of the /v2 APIs enabled.

We already have /v2/build (& /v1/build.json) which returns that info. Why do you want it w/ every request?

smiley.1438:

I wonder how that process would be easier with v2 since it basically delivers the same data. Currently the only way to find and update changed items is to retrieve the info for each and every item over and over. So the only advantage of v2 will be the bulk request which may speed up this process (which currently takes about a day).

That’s what I’m referring to, yes. Getting back 200 items at a time is going to speed up that process.

smiley.1438:

any chance on an endpoint which lists the ids of changed items after a patch has been pushed?

It’s not something we have currently, and I don’t think it’s anything we’re planning to build. Hopefully once /v2/items is out it’ll be easier for people to compile those sorts of things themselves.

We’ve been working on fixing a data issue with the backend WvW data for a bit. No ETA.

Thanks for the heads-up though!

The HOM is old & not heavily used, so it doesn’t get a lot of attention. Sorry about that!

If you do open that modal and get stuck you should be able to just refresh via the F5 key, no need to re-enter your character name.

We could expose the commerce search endpoint, but it only knows about items that can be put on the Trading Post. We don’t have any other search backends wired up to items that I’m aware of.

Fix deployed, http://hom.guildwars2.com looks fine to me. Anybody confirm?

Yikes, sorry about that. I’ll take a look at this.

Yeah, we chatted about it some internally and have a hypothesis. There was a bug around launch that let you place buy orders for items before they’d ever been “discovered” (sold). Folks were using our unsupported web service endpoints in the TP to place buy orders by incrementing item IDs blindly, so there’s all sorts of weird gunk on there now.

Commerce team is looking at how hard it’d be to clean that stuff up because it’s just cluttering things and making for weird situations like this. Since those items have never been discovered in-game (unsurprising, given that they’re internal-only NPC things) the items endpoint doesn’t know anything about them. That disconnect sucks, so we’d like to clean it up.

StevenL.3761:

Oooh I had no idea that nodejs works with IIS.

It’s not nodejs, it just works like it. We use ARR as a load-balancer and HTTPS endpoint which is why you’re thinking we use IIS.

StevenL.3761:

Is the public API written in .NET? You might be able to get better performance if you use Task.WhenAny() to process requests as soon as they complete. Waiting for all requests to complete before handling their response means wasted CPU time. Client applications will benefit as well if they support streaming JSON while it is still being created.

We don’t use .NET & for simplicity’s sake we don’t stream responses right now. We’re processing each individual request as soon as it completes but we’re not blocking on the responses or anything. It works like nodejs, conceptually.

Most use-cases for the data in /prices don’t actually require the freshest data in the world. You can get it from /listings in that case if you do need data with a lower cache time, with the caveat that if it gets abused we’ll need to up the cache time on /listings until it isn’t much fresher than /prices.

The /v2/items API doesn’t know about 9102 either. I wonder if the /v1 API feeding it hasn’t been updated correctly? Not something I’ve got a hand in so tough to answer.

/v2/items API isn’t active yet as we’re still polishing up some bits. I’m just providing examples to hopefully answer questions and maybe unblock folks that are writing libs that want to consume /v2 APIs.

smiley.1438:

Pat Cavit.9234:

smiley.1438:

Way more interesting would actually be the [item_type] part (hope you also changed the naming of that because it was a pain to “guess” the right identifier for that subobject).

Example:
https://api.guildwars2.com/v1/item_details.json?item_id=49412

Nope, sorry. That’s still passed-through as-is. Only difference is that we send back numbers as numbers instead of strings.

Oh, that isn’t too bad at all, though. Thanks for the info! However, any chance to get that subobject renamed in a more common way, something like “item_details” (or “itemDetails” in correct camelCase) or just “details”?

I misunderstood your question, sorry. It’s been standardized to “details”. I updated the gist w/ examples of the item you used.

https://gist.github.com/tivac/59fbb6474fece53ad97b

smiley.1438:

Way more interesting would actually be the [item_type] part (hope you also changed the naming of that because it was a pain to “guess” the right identifier for that subobject).

Example:
https://api.guildwars2.com/v1/item_details.json?item_id=49412

Nope, sorry. That’s still passed-through as-is. Only difference is that we send back numbers as numbers instead of strings.

StevenL.3761:

Will the json schema for item details change at all? Or will it be the same as v1, but with added support for bulk requests and pagination?

Very similar, but we’ve fixed some types & done some of the work for you in terms of turning items into icons.

https://gist.github.com/tivac/59fbb6474fece53ad97b

The /v2 api combines the /v1/items.json & /v1/item_details.json APIs into a single, simpler API. You can look a /v2/commerce/listings for an example of the behavior. Requesting the root of /v2/items returns a list of all item IDs, exactly like /v1/items.json. You can then request for /v2/items/<id> or use any of the other querying mechanisms like ?ids=<id>,<id>,<id> or pagination to get individual item details.

Wolf Fivousix.4319:

Does the BL inside the game use either listings or prices? You just made me think that, if the results are cached, then the data we see in-game isn’t live? Or does it use other mechanism unavailable to the API to be live?

The TP uses the same backend APIs that both /v2/commerce/listings & /v2/commerce/prices uses. It doesn’t go through the public API layer though.

/v2/commerce/prices has a caching layer on the backend API, so the TP is getting identical values to the public API.

/v2/commerce/listings is cached on the Public API layer (currently for 1 minute) because the public API gets hammered much harder than the in-game TP. This is mostly due to folks spidering for the entire state of the market every few minutes, which no user would ever be able to do from within the game.

Gewd.8125:

Pat Cavit.9234:

/v2/commerce/prices is what we show in search results on the TP and totally usable for places where absolutely up-to-the-minute data isn’t necessary.

/v2/commerce/listings is closer to being live data, but is also more expensive for us to retrieve. It may end up getting a longer cache time on it to avoid problems on the backend.

I have a TP website and we use commerce/prices to update all the items.

I realize that they can’t be live, but going from 1 minute to 5 minutes is a huge difference when prices can change very quickly.

If it is stuck at 5 minutes, then I would switch back to using commerce/listings which seems to put a heavier load on the server as it takes longer to complete.

The cache times on those two APIs come from different places. /v2/commerce/listings I control, /v2/commerce/prices I do not.

That said, if /v2/commerce/listings starts stressing the commerce systems too much we’ll increase the cache time on the API frontends. Live data’s no good if folks are taking down the commerce servers to get it!

Try to use the right API for the data you need, basically.