v2 item_details and recipe_details?

#3 - Sept. 17, 2014, 2:31 p.m.

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.

#5 - Sept. 17, 2014, 3:52 p.m.

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

#7 - Sept. 17, 2014, 4:06 p.m.

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.

#10 - Sept. 17, 2014, 4:19 p.m.

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

#17 - Sept. 18, 2014, 4:21 p.m.

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.

#20 - Sept. 19, 2014, 5:24 p.m.

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.

#24 - Sept. 20, 2014, 12:40 p.m.

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.

#27 - Sept. 21, 2014, 12:51 p.m.

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.

#29 - Sept. 22, 2014, 1:10 a.m.

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.

#31 - Sept. 22, 2014, 11:32 a.m.

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

#34 - Sept. 22, 2014, 12:29 p.m.

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.

#38 - Sept. 23, 2014, 10:43 p.m.

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

#47 - Sept. 26, 2014, 12:50 p.m.

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.