Yes the Nub Navi wants to f**k over noobs... Oh wait.
Discussion around the API
Started by Kivou [2000607] on in Suggestions.
Posts archived: 36 / 36 posts (100%) · the total is Torn's reply count + the opening post at the last fetch
Even just adding versioning, due to that underscore change our live chain reports broke. Fairly annoying mid chain when you intend to literally use it that evening to determine various things...
Ended up helping a friend to build our own live tracking system, very stressful indeed!
Ended up helping a friend to build our own live tracking system, very stressful indeed!
Dont feed trolls xD obviously everybody benefits from torn apps/external sites, specially noobs who fly for their income
^
Either Skelto was ironic in his post or he's thick as a brick. I'm a humanist so I think it's the former.
Anyway, it get things out of track and even with humor I'm not sure attacking either side with fallacious arguments will get us anywhere.
Either Skelto was ironic in his post or he's thick as a brick. I'm a humanist so I think it's the former.
Anyway, it get things out of track and even with humor I'm not sure attacking either side with fallacious arguments will get us anywhere.
No need to give special access / priveliges to certain developers - this should be public changes so everyone can see.
I'd be open to discussing topics with developers directly to provide some feedback though, thats something else entirely.
I think the previous change from camelCase to snakecase was handled allright. We got an announced change, devs provided feedback, and the change was done over two weeks instead of one. That meant we had a week to update sites and scripts to accomodate to the changes we knew were coming while the previous scripts were still working.
I'd be open to discussing topics with developers directly to provide some feedback though, thats something else entirely.
I think the previous change from camelCase to snakecase was handled allright. We got an announced change, devs provided feedback, and the change was done over two weeks instead of one. That meant we had a week to update sites and scripts to accomodate to the changes we knew were coming while the previous scripts were still working.
Good Answer 10/10 for you...
As upsetting as my satement might be it is a shared view. Noobs also want but dont see how without all the extra bits that old salty has installed.
So thank you for clearing that up.
As upsetting as my satement might be it is a shared view. Noobs also want but dont see how without all the extra bits that old salty has installed.
So thank you for clearing that up.
Im alot of both, im a noob so what do i know... i guess it also gives failed hackers and unemployed developers something to do.... a hippo cause i use one ...and i didnt know the mechanics for the system well enough to see it balance out anywhere, but another guy explained that one to me..
When I make a potentially breaking change, I put it up in that API thread at least a few days in advance. If I make a mistake, I quickly revert it or immediately find some solution. I'm really not sure what more you want from me.
We can bureaucratize the API and add versioning and all that other stuff, but it's going to reduce my freedom, make things more complicated for developers who want to use the API, take development away from other areas while that functionality is under construction, and future API releases / updates may be delayed or declined - so it's a pretty substantial trade-off.
We can bureaucratize the API and add versioning and all that other stuff, but it's going to reduce my freedom, make things more complicated for developers who want to use the API, take development away from other areas while that functionality is under construction, and future API releases / updates may be delayed or declined - so it's a pretty substantial trade-off.
The issue is what you see as a breaking change. It's a simple flow to know though:
Versioning doesn't seem like a great solution, in fact it could even be worse than now. We'd be at `api.torn.com/v765` fairly soon. A notice about a week in advance would be enough.
- Did the key change? Yes => breaking
- Did the value change? Yes => breaking
Versioning doesn't seem like a great solution, in fact it could even be worse than now. We'd be at `api.torn.com/v765` fairly soon. A notice about a week in advance would be enough.
Personally, I think a version ID would be useful, but not like DeKleineKobini has said. It can always be the same URL
Include a schema version in the API response. When a new API update is due out, tell us the new schema version number and that is due to change.
We can write our apps and check the schema version.
Assume we currently are on version 100, we know that key is XYZ. On version 101, it becomes X_Y_Z, it is easy add code to check the version and change what we are looking for.
This way, we can update our code early and when the API update happens, we dont have broken apps or have to rush to patch because the API update has just happened
For those that dont want to use the version ID, just carry on as before.
Include a schema version in the API response. When a new API update is due out, tell us the new schema version number and that is due to change.
We can write our apps and check the schema version.
Assume we currently are on version 100, we know that key is XYZ. On version 101, it becomes X_Y_Z, it is easy add code to check the version and change what we are looking for.
This way, we can update our code early and when the API update happens, we dont have broken apps or have to rush to patch because the API update has just happened
For those that dont want to use the version ID, just carry on as before.
100% agree with DeKleineKobini. Perhaps the issue is that we don't agree on what a 'breaking change' is.
For most of us, a simple change in the name of a key constitutes a breaking change. Even if it's a good change for the future and something we can benefit from, if we are not prepared for the change it will break our applications. Changing from 'respect_gain' to 'respect' is a good example of a breaking change (I'm not trying to insist with this, just using the last example we have available). There are things that can be done to minimise the consequences, like isolating functionalities, error catching, etc... but something will stop working for sure.
In my case, I'd appreciate if at least a 2 weeks notice can be given in these cases (mobile releases take longer)... or better, if both keys can be working simultaneously for several weeks, so that we don't have to time the change precisely or be prepared to accept two keys, one of which will fail.
Also, the ideal solution (or a compromise at least, as Wootty suggest) would be to work with different schema versions. This would ensure that old apps continue to work (even if they don't include new funcionalities). As it is right now, if a developer is not constantly updating the code, the average lifespan of an app is quite short.
For most of us, a simple change in the name of a key constitutes a breaking change. Even if it's a good change for the future and something we can benefit from, if we are not prepared for the change it will break our applications. Changing from 'respect_gain' to 'respect' is a good example of a breaking change (I'm not trying to insist with this, just using the last example we have available). There are things that can be done to minimise the consequences, like isolating functionalities, error catching, etc... but something will stop working for sure.
In my case, I'd appreciate if at least a 2 weeks notice can be given in these cases (mobile releases take longer)... or better, if both keys can be working simultaneously for several weeks, so that we don't have to time the change precisely or be prepared to accept two keys, one of which will fail.
Also, the ideal solution (or a compromise at least, as Wootty suggest) would be to work with different schema versions. This would ensure that old apps continue to work (even if they don't include new funcionalities). As it is right now, if a developer is not constantly updating the code, the average lifespan of an app is quite short.
Bureaucratizing and versioning are two different things.
Bureaucratizing is definitely going to reduce your freedom, but we know the best ways to build an api, since we use your and other apis beyond your api constantly. I WISH I could give feedback, but I don't care to if you are not accepting feedback... I (personally) will roll with your punches.
Versioning... I disagree with DKK. I think that adding a v765 is very important to distinguish breaking changes. For a computer, it can handle near infinite versions like that with no problem. And when a breaking change like the name of a key or the type of the output (array, object w/ key or dictionary whichever terminology you prefer) happens on the next version, apps that would break would still work under previous versions... but would have to update their code to newer versions to use newer functions.
On Wooty's perspective, it's pretty simple to make the check even without a schema version response, but it's going to result in messy code of spaghettis patches.
Bureaucratizing is definitely going to reduce your freedom, but we know the best ways to build an api, since we use your and other apis beyond your api constantly. I WISH I could give feedback, but I don't care to if you are not accepting feedback... I (personally) will roll with your punches.
Versioning... I disagree with DKK. I think that adding a v765 is very important to distinguish breaking changes. For a computer, it can handle near infinite versions like that with no problem. And when a breaking change like the name of a key or the type of the output (array, object w/ key or dictionary whichever terminology you prefer) happens on the next version, apps that would break would still work under previous versions... but would have to update their code to newer versions to use newer functions.
On Wooty's perspective, it's pretty simple to make the check even without a schema version response, but it's going to result in messy code of spaghettis patches.
As a former systems analyst, I'd have to say that design freedom does not extend to external interfaces. Changes to external interfaces should always ensure backward-compatibility is preserved.
Now don't get me wrong, the API I think is one of the best developments Torn has brought out, to give power to people to do some amazing things, which indeed they have.
Putting a post in a forum thread however 2 days before a breaking change is a little unfair to developers (internal and external) and the wider community as a whole (after all, isn't that who the API is for).
Could we not have something more pro-active to notify of upcoming changes? This is the 21st century after all, e-mail distribution, discord notifications, the options go on and on....
Putting a post in a forum thread however 2 days before a breaking change is a little unfair to developers (internal and external) and the wider community as a whole (after all, isn't that who the API is for).
Could we not have something more pro-active to notify of upcoming changes? This is the 21st century after all, e-mail distribution, discord notifications, the options go on and on....
100% agree.
Thank you,
Dont let them hijack your shit boss, for the love of torn, dont.
The gaming mass vs 1%ers ...
Unfortunately the big picture is lost of the ego driven.
Dont let them hijack your shit boss, for the love of torn, dont.
The gaming mass vs 1%ers ...
Unfortunately the big picture is lost of the ego driven.