Steam Web API/Feedback

Problems

Data layout & error handling inconsistency

This is really important for a good API: Almost all methods response with other data layouts. While the TF2 methods (except that for the Golden Wrenches) have a consistent layout. All other methods respond with different data. This isn't a huge problem for single applications, but for a library that wants to abstract access to the Web API.

• I was happy to see the first two TF2 methods having a unified layout and error handling and integrated a pretty nice abstraction into my library Steam Condenser. But this doesn't fit the all the other methods that came afterwards and pretty much obsolete any effort to abstract API access into a single class. --Koraktor

As TF2's methods are pretty much everything that's needed, I'm fine with it the way it is, but to be honest, all reponses should more or less look like the follwoing:

response
 \
 |-status
 |  \
 |  |-code
[|  \-detail] # This is only needed for errors (or warnings, e.g. "Your API request limit is almost reached: 10 left")
 \-data
    \
    .
    .
    .

API Considerations for Web Developers

Currently, the "Steam Web API" isn't very forgiving to web developers. There is a lack of support for the JSONP protocol and the API's acceptable usage policy requires that the API key is not to be shared. As described, using this API key inside of a Javascript file (which is downloaded in full source by the client) would be against the policy that Valve has provided. This requires that anyone wanting to create a web site that makes use of this data would be required to run a proxy (which I have personally done) in order to properly hide the API key. This could be remedied by changing the usage policy to allow "sharing" of the key, or to simply provide a mechanism that provides public keys that work along-side the private ones.

An API that I am working on strictly enforces that a proxy be used in it's current implementation, but I hope one day to allow someone to provide their API key in their Javascript files and download API data through a jsonp request. This would be ideal for wider usage in the web world. monokrome 04:37, 1 August 2010 (UTC)

Allow custom profile nicknames in the API

Right now you have to know the 64bit SteamIDs for any player related API call. The old community XML allows using the players nicknames (a.k.a. custom URLs). This seems to be a must-have for the Web API.

Suggestions

Provide more information about player profiles (like the old XML interface)

ISteamUser should either have another method to get the entire information about a player (e.g. friends, groups and games) or GetUserSummaries should provide these (with an optional argument):

• http://api.steampowered.com/ISteamUser/GetPlayerProfile/v0001/?steamid=XXXXXXXXXXXX
• http://api.steampowered.com/ISteamUser/GetPlayerSummaries/v0001/?steamids=XXXXXXXXXXXX&full=1

Provide games and packages information

There should be something like ISteamGame to retrieve information about every game available on Steam. One method to get all games and one for detailed information about one game, e.g. appid, name, release date, publisher, achievements, store link, price (depending on the country code) etc. and all subIDs (packages) they're included in.

Equally there should be something like ISteamPackage to retrieve information about every package available on Steam. One method to get all packages and one for detailed information about one package. e.g subid, name and all appIDs of games, that are included and price (depending on the country code).

Both interfaces also should have a third method that only returns a "last update" time stamp of the games / packages list to decrease traffic. This way a developer only needs to update his data if the time stamp has changed.

Search for players and groups

A feature to search for community profiles and groups would be nice, too.

Provide language options

For methods that may return localized data (like ISteamUserStats/GetGlobalAchievementPercentagesForApp) an additional parameter (lang or language) should be available to provide a two-character language name. ITFItems_440/GetSchema is already doing this.