Item id's on the site vs schema id's

[ЫъГЬ]

It seems, some item id's do not correspond id's from official schema (and thus used by most other resources). Any reason for that? And how can I predict them being different?

For example, Syringe Gun schema id is 17, but backpack.tf uses 204

 

On a slightly related note, can we get debug option for API? Developing with 5 mins limit between request is pretty painfull... It can give prices only for a bunch of crates or something, which will only make it more convinient in fact.

[Uranium235]

How about a simple mockup and / or cache for debugging? A cache might also be handy in production.

[ЫъГЬ]

I do cache, but it wouldn't help woth debugging the request itself. That simple process took quite a time solely because of the limit. I.e, my API key turned out to be invalid because I didn't enter site/description, but the 403 it gave was indistinguishing from 403 from 5 min timeout.

If you're talking about backpack.tf side, I do agree, I don't understand why it gives 403 instead of cached version with 304 to be honest. That would also nullify the problem.

[Uranium235]

I assume backpack.tf does cache, at least for the price API. Haven't looked at the http response header, but I would guess they are also set up to allow client side and proxy caching.

Depending on your program's platform, I was thinking about your own cache and mockup server.

 

But if the API does send a 403 for both, 5 min restriction and invalid API key, without specifying the reason in the body, I agree, that might be confusing.

[ЫъГЬ]

It doesn't give away cached version in between responses. After you made first request and got prices, your next request within 5 minutes will get 403 with an empty body.

[Uranium235]

The caching in between the 5 minutes should be your, the client's, responsibility, assuming the header allows that, and assuming you and the API are RFC compliant.

If the server also has an internal caching mechanism to ease the server and database workload, is unknown and irrelevant.

It would defeat the purpose of the 5 minute restriction if you simply get a server side cached version instead of a 403.

 

 

You may only request the prices once every 5 minutes. If you request before 5 minutes has passed since your last request, you will receive a 403 error. You should be caching these prices on your side, a 1 hour delay before fetching new prices should be sufficient for anyone's needs.

 

But it's true, you also get a 403 for an invalid API Key without having any chance to distinguish the two cases in a stateless environment.

 

I would give a JSON Object in the body that describes the actual reason, like most (Google) REST APIs do.

[Brad Pitt]

I do cache, but it wouldn't help woth debugging the request itself. That simple process took quite a time solely because of the limit. I.e, my API key turned out to be invalid because I didn't enter site/description, but the 403 it gave was indistinguishing from 403 from 5 min timeout.

If you're talking about backpack.tf side, I do agree, I don't understand why it gives 403 instead of cached version with 304 to be honest. That would also nullify the problem.

 

Couple of things here. First, the limit was imposed because of a bug in the backpack.tf plugin that made 200+ game servers request the pricelist every second. That meant the site was crazy slow, because even though the servers were getting a cached version (i.e., no CPU hit) -- it was using pretty much all the bandwidth and handling all these requests was quite ridiculous.

 

The v3 timeout was lowered 1 minute yesterday. Also,  if you're debugging -- You can save a local copy on your side and just develop using that local copy if you're going to query it more than once every 5 minutes.

[ЫъГЬ]

Ah, I see then. Well, anyway, that was just a minor issue that I worked around.

 

What about the actual issue with item ids? From what I noticed it only affects stock weapons.

[Brad Pitt]

Some IDs were merged because there are multiples of them in the database, like Bat and such. It is true that I haven't documented that at all, so here's a raw portion of code that'll help you out hopefully:

 

 

 

            0 => 190,
            1 => 191,
            2 => 192,
            3 => 193,
            4 => 194,
            5 => 195,
            6 => 196,
            7 => 197,
            8 => 198,
            9 => 199,
            10 => 199,
            11 => 199,
            12 => 199,
            13 => 200,
            14 => 201,
            15 => 202,
            16 => 203,
            17 => 204,
            18 => 205,
            19 => 206,
            20 => 207,
            21 => 208,
            22 => 209,
            23 => 209,
            24 => 210,
            25 => 737,
            30 => 212,
            29 => 211,
            160 => 294,
            735 => 736,
            831 => 810,
            832 => 811,
            833 => 812,
            834 => 813,
            835 => 814,
            836 => 815,
            837 => 816,
            838 => 817,
            5999 => 6000,
            2093 => 5020 // name tag
 

[ЫъГЬ]

Yes, that's perfect, thanks.

[Uranium235]

Some IDs were merged because there are multiples of them in the database, like Bat and such. It is true that I haven't documented that at all, so here's a raw portion of code that'll help you out hopefully:

 

Would it be possible to add that mapping to the result?

That way scripts can adjust automatically instead of having to update the code.

 

{
	"response": {
		"success": 1,
		"current_time": 1362339098, // this will return the time when cache was generated
		"prices": {
			"35": ...
		},
		"defindex_map": {
			"0": 190,
			"1": 191,
			"2": 192,
			"3": ...
			"2093": 5020
		}
	}
}

[Brad Pitt]

That's a great idea, I'll look into it!

[Uranium235]

That's a great idea, I'll look into it!

 

Sorry to necro-post, any update on this?

Since it would not change compatibility with the current API version, it could just be added.

[Brad Pitt]

This has been added to the v3 API. Enjoy