Torn-Playground / tornapi-documentation

Unofficial documentation for the API of Torn.

Home Page:http://tornapi.tornplayground.eu/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

War reports factions multiple keys

DeKleineKobini opened this issue · comments

image

I don't think this follows the rules of rest of the schema. It's a object / dictionary that is represented by a key and a value type, and in this case that would be <faction-id> and Faction Object only. I would put the information that it consists of two factions in a description if there is a field for it.

Originally posted by @Llyfrs in #111 (comment)

commented

Ok I will try to explain the problem. I will be talking about my code, and I know everybody will have different approaches, but I think the loss in consistency here would hurt anybody using the API provided.

Whenever I approach something that has the symbol < in them I treat them as a hash map, because that's what they always are, so for example in revives, there is this structure:

image

which is telling us that the API returns HashMap / dictionary where the key is user_id and the value to that key is revive object. In my code that then looks like this:

type revives = HashMap<String, revive>;

This works everywhere else I think. But here, cuz you are suddenly deciding to write down each individual key-value pair, it would look something like this

type factions = HashMap<String, faction>
type factions = HashMap<String, faction>  // throws error

I still think the information should be provided that it returns fixed amount of results, but when it's provided this way, it may look ok on the website but break the consistency of the provided schema.

I think bigger problem here is that finding dictionaries is right now based on a character in a string, when it should be the same as array where it writes Array of Objects and when it's dictionary it would say something like Dictionary of Objects (Objects being replaced by that specific object obvs). This wouldn't even allow you to break consistency, something this system right now allows easily.

It would look something like this I guess
image

I 100% agree this is way worse in representing what value the key carries.

This would probably require a lot of rewriting so I don't actually expect it implemented lol, but it would be better way (imo) and I think you can see how, what is written in this situation wouldn't even be possible to a accomplish within that system.