For /v1, I used to have a single class per item type to hold type-specific item details.
Statically typed languages like C# do not allow “item.details” objects to take on different types according to the value of “item.type”.
For /v2, I need to rethink my design so that every possible item detail fits into a single class hierarchy.
Is anyone trying to do the same thing? Did you run into any problems with things like duplicate property names meaning different things for different item types?
edit
Does anyone use JSON schema validation? Is there a way to generate an aggregate schema from a number of different json documents? It would be interesting to see a tool that loops through all 38k items, then outputs a complete schema that describes all possible objects and properties.
The error code is useful to determine which parameter was invalid.
10 = invalid identifier
90 = invalid language
You could then use that information to do things like display localized error information, which is useful because error responses are always in English regardless of the given ‘lang’ parameter.
Forget about /v1, show us the numbers for /v2/items. The new APIs seem fast enough to not require asynchronous code, but I’m curious to see how far it can be pushed.
How many requests out of 1000 does it send and post-process at a time? Would you be able to queue up all 1000 requests at the same time, then handle each one as it completes?
My understanding is that the total duration should approach the sum of (the time it takes to queue all requests) plus (the time of the slowest HTTP query). How does it still take over a minute? (honest question)
I’m a little paranoid about the build number changing while I’m updating my database. My workflow now is to get the build number, then retrieve a batch of items, then verify that the build number hasn’t changed. Only if the build hasn’t changed can I be sure that each item was assigned the correct build identifier. If it did change, I have to discard that batch.
I could be mistaken, but doesn’t that refer to its chance of spawning? Meaning that the event start time is fixed, but it may or may not start depending on a roll of the dice.
Don’t worry about how long it takes to populate a database. You only have to do it once for the lifetime of the installation.
Wrong. Do you know how often even the names of items change? There’s some more languages than just english. Also, if you want to offer an extended search, you need to run an updater after every new build. There’s a reason why so many people asking for a list of changed item ids for each patch.
While the updater is updating the database, the search engine can still use the (partially) outdated data. The real problem is that right after installing the app, the updater hasn’t had a chance to bring the database up to date. So any given search would return 0 results until enough time has elapsed to populate the database.
Don’t worry about how long it takes to populate a database. You only have to do it once for the lifetime of the installation.
Lazy solution: create a database table with just 4 columns:
item_id
build_id
language
name
Then, create a background service that periodically checks for new item identifiers, and also keeps existing items up-to-date based on their build_id. The end result is a searchable index of items that is updated regularly.
You can decide to add additional columns based on how complicated your search engine should be: item_rarity, level, description (…).
For everything that isn’t going to be used by your search engine, do use the item_details.json API.
It looks to me as if these items are not supposed to be listed on the trading post. I converted some of the identifiers to chat links and pasted them in-game to see what item they correspond to. Items include things like “Cinematic Weapon Sword Charr”.
/commerce/listings only returns identifiers for items that are currently listed on the trading post. That explains why there are well over 15000 identifiers missing from the listing service.
What it doesn’t expain is why there are item identifiers in the listing service that are not in the items.json service?!
/prices is more useful for viewing by humans. You have to consider that people have a reading speed of just a few bytes per second (at 1 byte per character for UTF-8 encoded text). So live data is no longer live data by the time they reach the bottom of the page.
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.
I’ve always wanted to know why an item’s combat attributes is a collection instead of an object. Don’t you store each attribute as a separate table column?
Can items have multiple inherent attributes of the same type? Even if so, why not add them together?
You can still use v1 for now. The data that v2 will return should be the same. Only the response format will be different. Consider converting incoming response data to custom class layouts that are reusable for v2 when that becomes available.
I found the quaggan API very useful for testing different API options. My code had full support for /v2 request syntax by the time that the commerce services were enabled. I’m a happy Quaggan.
I’ll put in multiple layers of settings. From high to low priority : user defined language -> Local.dat language (if file is present and in a known format) -> system language (if supported) -> default language (English).
Still need to figure out the format first. It’s more complicated than I thought at first.
So: i’d say you can’t without violating the EULA. Since GW2 doesn’t store the settings in the windows registry but most likely in the /appdata/roaming/Guild Wars 2/Local.dat. So you’d have to find the setting in there or might hook into the game to find out. (But i guess you know that anyway)
Actually I didn’t know that, but I’ll look into it. If Local.dat is really where the language setting is stored, I should be able to find it by checking which bytes change when I change my language setting.
So that brings me back to my original question: can I detect the user’s in-game language setting somehow? That way, they can set my app’s language by changing their in-game language. And it will always be a valid value.
There is no way to accurately determine which language is actually returned (other than analyzing the value of the “name” property using some advanced language detection algorithm).
The only solution for now is to limit allowed values to values that are known to work. Which brings us back to the original problem: the system language might not be supported.
Is there a way to figure out the user’s in-game “Text Language” setting somehow? I’m afraid to go by the current system’s settings, because those include unsupported languages.
If the answer is no, could a dev please update /v1 to include Content-Language headers in the response? The API data defaults to English when the value of the “lang” parameter is invalid. That’s fine, but it should be reflected in the response when it happens.
My best guess is that listings are (lazily) loaded in parallel, so the order would be undefined. For practical purposes, that means that the list goes from listings with few offers to listings with lots of offers.
I think you can get better performance if you run multiple queries (for 200 ids each) in parallel. The ids=all would take too long to complete for a client application to just sit there and wait for the data to return.
So I guess I’ll implement an artificial limit of 200 identifiers in my code. Otherwise, I get problems where the API crashes and returns plain html when the URL becomes too big.
Not all /v2 endpoints support the “ids=all” identifier, but there doesn’t seem to actually be a limit on the number of identifiers that you are allowed to request in a single HTTP GET? I’ve noticed that it does break when the URL reaches some length. I’m not sure what’s up with that.
At least there is some communication now. What bothers me more is that they demonstrated the /v2/quaggans endpoint, but never even mentioned the /v2/commerce endpoints. If /v2/commerce were ready, wouldn’t they have told us that on the live stream when that one person asked about the APIs?
I had no idea that nodejs works with IIS.
