18 replies · 127 views · thread synced · 5 days ago
· View on torn.com
About this thread
Posts archived:19 / 19 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
19
Discussion span
→
People posting
6
Likes on archived posts
1
Posts by staff, officers and moderators
6
Authority score
73 / 100
Historical score
30 / 100
Story score
28 / 100
Engagement score
53 / 100
Most-liked replies
aurel1[1046304]Admin
· 1 likes · We are planning to expand api, but there will not be a big changes in near time I believe. However, some new selections may be added.
A general question to Torn admins/developers: what's the status of API development? Are you open to new features and enhancements requests? Or are you only fixing bugs, consider the API finished as is and won't add/modify nothing in the near future?
Why not? That's also can be done, but I think the changes of the current selections should go as new api version (current one is 1.0) - perhaps the 'next version in testing mode' so those, who already using current one will have a time to prepare?
Well, I inferred that partly from your previous reply but also because there are at least a couple of posts in this forum (one about using arrays instead of objects and the other about using numbers instead of strings) that would deserve an "official" answer, IMHO.
To be honest, I have more request to make: I'd like to be sure there's at least a chance that you'll consider them before posting. And, while we are on the subject, should I post here on the Suggestions forum?
Hate for some API suggestions? That would be surprising, but I wouldn't lose any sleep over it. I'm more concerned by the amount of insane bumping that quickly buries any not-so-popular topic.
Simple json is the easiest and the most common way to return the data, almsot all languages have their own tools to work with json, not sure why we need objects?
Sometimes 'numbers' can really be presented as 'strings' (this depends os some specifics of how they are stored), and most likely it will be fixed in near time, but that's not a huge issue - it's always better to use types casting on your side to avoid any kind of problems.
That's not what archimede asked for-- they were talking about the "Faction API: members list" topic suggestion. Still JSON.
And also, I have to disagree about your idea that it's always better for the clients to cast values: clients should *validate* data, not cast it. The API is supposed to be a technical contract between service and client, but it's currently broken by inconsistent return types.
I'm not saying it's difficult to cast data. That's very simple to do. But given consistent JSON responses, schema validation would make clients much more robust and even simpler to implement. And I know you already said it's gonna be fixed in the near future, but that kind of misconception is also affecting other parts of the API. I hope future versions are more consistent.
We have 'suggestions' forum for suggestions. This forum is more a one to discuss the current progress and features.
In this case your client is a layer, that operates data - if you want to just show it without any kind of changes, everything can be converted to strings. It's awlays better to cast values simply because in this way you will ensure, that any kind of data changes will not affect your logic (this may happend because of bug, or any kind kf changes, etc.).
By extension of the first part of that argument, the data supplied by the API should be reasonably typed and ideally conform to a published schema. By extension of the second part the users should refrain from whining when it isn't :-)
We're mixing topics, so it's difficult to follow the conversation, but...
> not sure why we need objects?
Not sure why you ask this. What I'm proposing is the opposite: use arrays instead of sending a bunch of objects.
Also, I hate to sound pedantic but JSON stands for JavaScript Object Notation:
- in Javascript we have arrays (in fact many popular frameworks rely on array of objects): so use them where it makes sense - in Javascript there is a BIG difference between 123 and "123": let's use quotes where appropriate, not just everywhere because clients can cast
The point Mauk and I are trying to make is that API should produce the most coherent data that is possible: of course clients will have to manipulate those data somehow, but why make their lives harder with no good reason?
I don't think we're whining: we're trying to point out what we consider areas of improvement for the benefits of the whole community (developers and users alike).
I think I already explained the situation with types in my thrid post - I am not trying to impose any kind of point of view, just telling how it's now and how it most likely will be.
Currently we are using the json string, that can be converted to array very simply?
> I am not trying to impose any kind of point of view, > just telling how it's now and how it most likely will be.
The first part sounds encouraging, the second part makes me wonder what's the point of having a discussion.
While I see good reasons to make the changes we're proposing, your only argument seems to be: "we know things are not ideal, but are simple to workaround, so we won't make any changes".
I'm afraid it will cause more harm than good in the long run, but if that's the case we'll have to live with it.
- We will fix bugs and make small changes (like strings->numbers) constantly. - We will add new selections sometimes. - We will change the structure of existed selections most likely only in new api version, that will replace current one only after some period of adoptation (after this there will be a new 'dev' version).