API user competition selection bugged

Tuesdays API update

- [API] Added competition information to 'user' -> 'profiles' selection

I'm having a problem with the new user competition selection

because the word competition is used twice in the same selection I cant split the string selection into 2 string, I get returned 3 strings instead

[image: i.gyazo.com]

The first competition mentioned needs to be competitions

need this sorted quickly so i can use this selection for the current Eliminations, not next week

either one will do
its the duplicated 'competition' causing the problem

"name":"Elimination"

will do fine Thank you

how soon until this is changed

I would like to get on with coding

as soon as possible, please

not everyone uses JSON

in Visual Basic I read the APIs and Read the data I require with routines I have written to read all the API's with one routine

the sub-functions I have written using Spit{Stings], InstrB{String], InstrRev[String] can read multiple types of API data and I can get the data as fast as any JSON and save the data as like catch memory, I don't have to reread data that doesn't need to be download again

Using the same variable name in the same section and has two different values

in any code, this is bugged

competition = selection
competition = elimination

The same variable cant used to return the correct data

Just because I don't use JSON that somehow gets around this doesn't mean coding rules should be broken

strict variable names should be used in all code

everyone uses different ways to read the APIs its not all JSON

This is 100% completely valid json, you need to change the bug in your code. Asking someone to change the names of their schema because you arent treating it as json is ridiculous. Your using a dotnet family language, there are plenty of libraries to deal with json

Please do not change this. The json is correct.

as i said above

NOT EVERYONE USES JSON

3rd party APIs are made for multiple systems and In a order to provide consistent developer experience across many applications

all names used by an API should be:

• simple
• intuitive
• consistent

The API information should not have more than one interpretation of a value in the same context of the API

Using JSON is really easy to get used to. I understand not wanting to change your code (probably not least because it's a hassle to write it like you did), but if an option that is so much better comes along... I think it's better to make the switch yourself, than change the response so dozens or more other developers have to change their stuff.

Your problem wouldn't exist if you used JSON.


Side note: when I wrote a Python based Torn IRC bot I did roughly what you did, avoiding JSON for a while because I didn't understand it, but switching made a looot of problems disappear. I think that would happen for you too.

This thread is not about JSON

It is a the structure and integrity of the API's and the use of ambiguous names within the context of the API's

They can lead to misunderstanding of API concepts. choose specific names that accurately describe the API concept.

read these rules

Naming Conventions

In order to provide consistent developer experience across many APIs andover a long period of time, all names used by an API should be:

• simple
• intuitive
• consistent

This includes names of interfaces, resources, collections, methods, and messages.
Since many developers are not native English speakers, one goal of these naming conventions is to ensure that the majority of developers can easily understand an API. It does this by encouraging the use of a simple, consistent, and small vocabulary when naming methods and resources.

• Names used in APIs should be in correct American English. For Example, license (instead of licence), color (instead of colour).
• Commonly accepted short forms or abbreviations of long words maybe used for brevity. For example, API is preferred over Application Programming Interface.
• Use intuitive, familiar terminology where possible. For example,when describing removing (and destroying) a resource, delete is preferred over erase.
• Use the same name or term for the same concept, including forconcepts shared across APIs.
• Avoid name overloading. Use different names for different concepts.
• Avoid overly general names that are ambiguous within the context of the API and the larger ecosystem of Google APIs. They can lead to misunderstanding of API concepts. Rather, choose specific names that accurately describe the API concept. This is particularly important for names that define first-order API elements, such as resources.There is no definitive list of names to avoid, as every name must be evaluated in the context of other names. Instance, info, and service are examples of names that have been problematic in the past. Names Chosen should describe the API concept clearly (for example:instance of what?) and distinguish it from other relevant concepts(for example: does "alert" mean the rule, the signal, or thenotification?).
• Carefully consider use of names that may conflict with keywords in common programming languages. Such names may be used but will likely trigger additional scrutiny during API review. Use them judiciously and sparingly.

Iv done my homework and this isn't about JSON

Please for the love of cthulhu do not change this. Aside from everything people have said above, its pretty clear this would be a change of convenience, in which case you only have to ask - how many people is this change actually going to help vs hinder. To which the answer is:

- help one dude who is using the api in an unintended way
- hinders literally everyone else in Torn who just built tools for Elimination

Cons of not changing:

- one guy has to figure out how to use json
- ?????

Pros of not changing:

- don't have to go through the effort of changing
- no one else's tools fail now and probably in the future when other examples of this crop up