Example: {"bazaar":{"1494547":{"cost":24500,"quantity":150},
The ID key should not be dynamic, and makes it difficult to reference to.
An example of how it should be...
{"bazaar":[{"id": 1494547, "cost": 24500, "quantity": 150}]}
Dynamic key in Bazaar API
Started by Stewie [1494547] on in API Development.
About this thread
Posts archived: 39 / 39 posts (100%) · the total is Torn's reply count + the opening post at the last fetch
Counted by TornLife from the archived posts.
- Archived posts
- 39
- Discussion span
- →
- Authority score
- 74 / 100
- Historical score
- 30 / 100
- Story score
- 45 / 100
- Engagement score
- 70 / 100
People posting, likes and official posts are not counted for this thread yet: on threads longer than one page they come from a periodic pass over the archive, which has not covered it.
Most-liked replies
- Mauk [1494436]
· 5 likes ·
Holy sh.. I'm out of here. - IceBlueFire [776] Officer
· 1 likes ·
We needed a unique value to identify each listing. Figured the best way to keep track of them (if you wanted to) was to use the listing ID, rather than just numbering them.
Example: {"bazaar":{"1494547":{"cost":24500,"quantity":150},
The ID key should not be dynamic, and makes it difficult to reference to.
An example of how it should be...
{"bazaar":[{"id": 1494547, "cost": 24500, "quantity": 150}]}
Agreed R+
Yeah it's a pain but obviously you can get around it.
For example, if you're searching through the entire list in JavaScript you can just loop over each unique key within the JSON data structure
The so called ID number is irrelevant.
It is a Database attribute ID number to itemmarket in Torn's bazaar database system which we have no access too.
for our use its just a reference of something that will not exists after the items are sold
you do not need to store or remember this number
it is only use it as partition or reference between items for sale, cost and quality.
the same data may not exists next time you refresh your API program
It is not an ID number
It's still an ID number, regardless if it points to a user, or not... My point still stands, the key should not be dynamic. If I wanted to reference to the cheapest bazaar and display (which is really what the API is about, to provide data for me to be able to read..) I should be able to do so without having to use some workaround.
I do not want the same data every time.
Bump
I don't get what your talking about, the data is different every time you refresh.
an item is sold, quantities are changed entity's are removed.
its the same information we see in Torn's itemmaket pages.
the cheapest items are displayed just the same.
I don't know what workaround you are looking for the data is simple, shows cost and quantity.
you just have to be quick go buy now.
It's not difficult. In mIRC I want to be able to do @cheapest and it will display "Cheapest bazaar: blah blah" and a link to the items market.. if the key is dynamic it is harder to reference to.
I mean, I do have a way to reference it, but it's stupid that it changes every time.
I don't mind the ID (whatever it's for), it should be like most of the API like this "id": 8574683, instead of "8574683",
Bump
Also, while you're on the topic, this applies to events too:
http://api.torn.com/user/?selections=events&key=
Not a pro at this sort of stuff, but I did manage a workaround for this; for PHP anyways.
I used:
$data = reset($data['bazaar']);
This made things a lot easier to work with :)
Not sure if that helps though :)
Literally just implement a for-loop.
It's not rocket science.
Come by my channel (or the ones that we are both in), my bot has it. It's pretty easy to do. :P
It's not that it's not easy to do. I *have* a way to do it with the JSON Parser I use which attempts to find the first "fuzzy" match. I just disagree with the JSON keys being dynamic.
They should be dynamic, so that you can use an order-respecting map.
Stockholm syndrome much?
It's even in the freaking name, "map." It maps Xs to Ys. If you don't previously know the Xs, the Ys shouldn't be in a map, but in a list.
https://pymotw.com/2/collections/ordereddict.html
Thank you, have a nice day. Don't forget to learn about for-loops.
Thank you, have a nice day. Don't forget to learn about for-loops.
Seriously, nobody is arguing it isn't possible to loop over the keys of a dictionary or a map. But being possible is no reason to use something. A lot of very stupid things are possible in computer science.
But, hey, keep up being enlightened by the awesome and intricate loops that are far too complex for us mere mortals to understand. In fact, we should probably petition for every API to use maps instead of arrays, that way it's super consistent and conceptually correct. We should also use strings instead of numbers, that way we don't have to worry about data types.
I'm not arguing it is; I'm merely pointing out that your comment of "Stockholm Syndrome" is an ad hominem argument, and an incorrect one at that. Ordered maps are not that special.
My point is that changing the structure of the API is not necessary to deal with the output it provides.
IMO Whilst yes its possible to deal with somewhat simply, it just doesn't make sense for it to be a map rather than a list. Doing this way makes it annoying to deal with outright.
JSON is a map by default.