Difference between revisions of "User:STUART/WebAPI"

From Team Fortress Wiki
Jump to: navigation, search
(Things that should be fixed in the Steam Web API system)
(Things that should be fixed in the Steam Web API system)
Line 1: Line 1:
 
==Things that should be fixed in the Steam Web API system==
 
==Things that should be fixed in the Steam Web API system==
*JSON and VDF should use arrays rather than objects containing arrays. Having them structured differently from XML complicates code unnecessarily (and result.items.item[1] is redundant compared to results.items[1]). This seems to have been designed to preserve the element name used for the individual objects in XML (allowing multiple arrays to be defined in the event of mixed types, which should never happen). When everything in an array is of the same class, nobody in JSON cares about that class's name (only its index in the containing array, and anybody using VDF is using code that was written for the original data file, which ''is'' structured this way.
+
*JSON and VDF should use arrays rather than objects containing arrays. Having them structured differently from XML complicates code unnecessarily (and result.items.item[1] is redundant compared to results.items[1]). This seems to have been designed to preserve the element name used for the individual objects in XML (allowing multiple arrays to be defined in the event of mixed types, which should be structured as multiple arrays in XML as well). When everything in an array is of the same class, nobody in JSON cares about that class's name (only its index in the containing array, and anybody using VDF is using code that was written for the original data file, which ''is'' structured this way.
  
 
Short version: this
 
Short version: this

Revision as of 04:07, 5 July 2010

Things that should be fixed in the Steam Web API system

  • JSON and VDF should use arrays rather than objects containing arrays. Having them structured differently from XML complicates code unnecessarily (and result.items.item[1] is redundant compared to results.items[1]). This seems to have been designed to preserve the element name used for the individual objects in XML (allowing multiple arrays to be defined in the event of mixed types, which should be structured as multiple arrays in XML as well). When everything in an array is of the same class, nobody in JSON cares about that class's name (only its index in the containing array, and anybody using VDF is using code that was written for the original data file, which is structured this way.

Short version: this

 "result": {
   "status": 1,
   "items": {
     "item": [
       {
         "id": 18446744073709019323,
         "defindex": 125,
         "level": 1,
         "quality": 3,
         "inventory": 2149580806,
         "quantity": 1
       },
       {
         "id": 1029705,
         "defindex": 36,
         "level": 5,
         "quality": 3,
         "inventory": 2147483655,
         "quantity": 1
       },
     ]
   }
 }

should look like this:

 "result": {
   "status": 1,
   "items": [
     {
       "id": 18446744073709019323,
       "defindex": 125,
       "level": 1,
       "quality": 3,
       "inventory": 2149580806,
       "quantity": 1
     },
     {
       "id": 1029705,
       "defindex": 36,
       "level": 5,
       "quality": 3,
       "inventory": 2147483655,
       "quantity": 1
     },
   ]
 }

Methods that should be added to ITFItems_440

  • A method that, for resources/tf_english.txt, returns what GetSchema does for scripts/items/items_game.txt. The latter's not very useful without the former as far as output is concerned.
  • A method that returns the latest revision information for each of these, so systems know when they need to make the heavy call to GetSchema (and the hypothetical method that returns language data).

Things that should be added to the next version of GetSchema

  • The revision number, so systems can compare it (for stored data) against the latest revision (as described above).
  • The defindex of attributes for items, rather than the attribute's name and class. If GetPlayerInventory uses defindex for its attributes, GetSchema should too.

Things that should change in future versions of GetPlayerInventory

  • Ditch the "quantity" field. With a unique ID on the item, how can this be anything but 1?
  • Separate the "inventory" field into an "inventory_slot" value and "equipped" object (with a "true" for each class the item is equipped for, and empty if no classes have the item equipped). This is a Web API: consumers shouldn't have to do binary operations to get at data.