API Discussion

[Erorus]

I'd like to continue the API discussion from the devblog.

Proposed specs:
XML and JSON available
Will need a login in User Controls, and a unique key generated within
Will be throttled by bandwidth/processing time per hour
All requests will be limited to one realm at a time, unless otherwise specified.

A visitor emailed me with some very good notes. There could be 3 API categories: raw, history, and aggregate.

Raw data: the most recent data scanned from the auction house. Can filter by itemid(s) or seller(s), or get everything.

History data: get a list of all auctions for a given item/seller, including time first seen and time last seen, for a given time period up to two weeks.

Aggregate data: get the market price and quantity available for given item(s). Plus anything else calculated by the site and not "raw."

Sales data is likely not going to be included because it's not very accurate. False positives are minimized but I'm still not comfortable with it.

Bandwidth concerns: the auction database sits behind an asymmetrical DSL connection. Uploads from the database to the world are not high speed. This works well for the "summary" type information currently on the web, but APIs that request a lot of data would need to be limited. This is one of my greatest concerns with offering history data.

Blizzard will soon (tm) have their own API which will offer great live data, and maybe more. So I probably don't need to go too overboard with this.

Any thoughts?

[Belgeran]

What your offering sounds awesome and perfect for what i wanted to implement.
Basically i wanted market notifications sent to irc, as well as letting people do !price $server $itemid, scraping the html page worked fine but anything more than the occasional lookup would be a a huge bandwidth hog so once i read you were doing an API i put a halt to my plans.

Looking forward to your API and or blizzards. By the way, love the site its a great great idea.

[Pliaksi]

I know , I might be dreaming a bit here, but here are a few things I would love to see:
- A highly customisable query: maybe I'd like to get the item id's only instead of full names (to preserve bandwidth) or maybe I'd like to get all the current + historical data of a list of items in one request. While I am by no means expert in web programming, maybe you could provide an interface that fully supports SQL queries to your DB.
- If none of the above is possible, a filter by faction would be nice.
- Some more aggregations such as the median, geometrical mean and moving average (though I fully understand that this might not be the most used data).

Anyway thumbs up for what you are already doing, and hope to see you in EU soon too.

[ReaperSA]

Any chance of a priceing datafeed? Maybe publishing vectors via a webservice or something similar?
Maybe even a look at a tcp / ip remoting type of feed. This could be done with only sending out vector updates and not a full stream of data.

Process would be login / get all item base information i.e open price / prev close. Then continualy publish stream of price / trade updates.

[Stede]

A personalized summary page would be nice. It could pull basic pricing info, like what you have for the Profession pages (market price, mats price, movement, 95% CI) for a customized list of items. It could be part of each user's settings page or something like that. You'd probably want to cap the number of items that each user could put on the list at something reasonable, though.

[Unregistered]

First off thanks so much for this site , it is simply awesome what you've managed to achieve !

As for API suggestions ; I'm mainly interested in pricing trends over time. Providing a distribution table would be great. Something that gives quantities per bin for a given bin count (ideally an optional value) would be perfect.
See http://en.wikipedia.org/wiki/Histogram for an idea of what I'm thinking.

Additionally, It would be really cool to separate the acquisition of the data from the operation(s) performed on it.

By this I mean, that I could specify my query in terms of exact or partial matches (including ranges; the most obvious being time) on the data and then a different parameter would identify how I want the results processed (e.g. raw, averaged, distribution, summary etc.). Ah, but I'm probably stepping on your design toes now, so I'll back off.

[Unregistered]

Oh also forgot to mention that its probably easiest to pick one of XML *or* JSON and not support them both.

It will make testing / bug fixing and general interaction with the community less of head ache, since we'd all be talking the same lingo; my vote is for JSON but either one is fine.