Dynamic key in Bazaar API

Not really?

JSON specifies 7 primative values: string, number, object (/map), array, true, false, null

Im not understanding what you are saying because even if so, even if "by default json was a map" then what does that matter from a logical standpoint? Should we define numbers in object format too in that case?

Those are the data types JSON can contain.

The format itself is considered a map that maps keys to values.

I'm not really arguing about the structure of the API. The structure is only a small part of it.

Here is my problem: {"bazaar":{"1234567":{

That value is hard to reference to, (at least, it seems to be within mIRC (mSL))

It is for the most part, poorly structured like this (as well as a lot of other places in the API.)

There is no key for that value though.. well, that is the "key", but I cannot reference that.

"cost":24500, has the key "cost" and the value "24500"

I am by no means arguing that the number cannot be dynamic, as, yes, it should be.

I do not care to track that number, it's not that number I need... but, with the parser I use I would do $JSON(<handle>,bazaar,<number>,cost). I cannot reference cost without that number.

That's exactly the reason it shouldn't be used as a map key.

--

"The format itself is considered a map that maps keys to values."

Yeah, it actually isn't. "null" is a completely valid JSON, and so is "54" or "[12,25]." They really, really aren't maps. Please, refer to the JSON standard if you still don't believe that.

I didn't mean it shouldn't be included. Just.. inside the object, in an array.

I think people are getting confused. We're not saying it should not be there, its more on the lines of it should not be used as the key portion of a key value map, it doesnt make sense. Your bazaar item list is a list. The API should return a list of items in your bazaar rather than a map that uses the ID as keys,.

Not only is that wrong its also completely goddamn irrelevant regardless. No one is saying it couldnt be { "bazaar": [ Actual list/array of items ] } in fact that is what Stewies first post states as an example.

Edit: Didn't mean that to come off as harsh...

All Torn API calls will provide you with a map. Not an array, not a list, not with a Null object, not a NoneType object. A map.

Whether other things are possible is completely beyond the scope of my point.

https://en.m.wikipedia.org/wiki/Straw_man

Holy sh.. I'm out of here.

Can you repeat what your actual point is? I'm completely missing it currently reading back through your posts. It seems you are arguing something irrelevant to what this topic is actually about.

Yes all Torns API calls provide a map, but the value of the bazaar property/field should be a list of items. It doesnt make sense that the value is a object/map of bazaar row id -> amount.

I'm afraid you have to give up.

For some reason, someone decided that arrays inside JSON are evil/complicated/unnecessary/whatever: I already tried to suggest this isn't a good idea (eee here) to no avail.

You'll have to live with the current state of affairs.

Happy coding.

Arrays are simple to work with in JSON.

Objects are harder to work with as its harder to reference to.

I don't think that Stewie is saying the listing ID should be removed.

Rather, restructure the api tp include the listing IDs as arrays to make it easier to reference to.

If you need to have the IDs as keys for each object you could do something like this:

https://jsfiddle.net/k5f0wjdt/ - Remember to insert your API key to test.

For example:

This function will turn a 'bazaar' JSON from:

{"bazaar":{"1494547":{"cost":24500,"quantity":150},

To

{"bazaar":[{"id": 1494547, "cost": 24500, "quantity": 150}]}

I use python and order it by cost then quantity in one line.

for playerID in sorted(BazaarPrices, key=lambda x: (BazaarPrices[x]['cost'], BazaarPrices[x]['quantity'])):

My thoughts are that if it is not a major improvement no changes should be made.

To be honest your last point was a better reason than any given by anyone else in this thread.

That being said, please for future API endpoints use an array of objects. It doesnt matter in the grand scheme of things really it just means I dont have to go about converting from an object to an array of objects. It removes one step. It makes more sense to do it this way.