Skip to content
TORNLIFE More

[API] standardise types in API responses

Started by pobk [3171827] on in Bugs & Issues.

90 replies · 1.36k views · thread synced · 3 days ago · View on torn.com
About this thread

Posts archived: 91 / 91 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
91
Discussion span
→
Authority score
63 / 100
Historical score
49 / 100
Story score
60 / 100
Engagement score
80 / 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

  • Manuito [2225097] Committee · 19 likes ·
    This unplanned API change has rendered Torn PDA unusable
  • Chedburn [1] Admin · 13 likes ·
    I was thinking we can add a v2 where I'm allowed to make fixes and changes without a fuss, and then everyone can just use v1.
  • Chedburn [1] Admin · 11 likes ·
    The v2 versioning is now complete... https://api.torn.com/v2/user/?selections=profile&key=X Currently it's identical to /v1/. Before people start using it, I'd love for us to make a load of simple changes and fixes like you've mentioned on your list, but I don't know …
pobk [3171827] · #1 · edited
The API currently has a number of endpoints that return values in the incorrect types for JSON exchange.

If it's a float, please return a float; I'm looking at /user/?selections=skills where floats are being returned as strings - Why?!!!

If it's an int, please return an int; example here - /user/?selections=attacks where empty string returned if there's no value - Why?!!!

if you have a null value, please, just return null.

I don't care about datetimes, because I normalise to UTC anyway, however, standardisation on, perhaps epoch timestamp with TZ Info of UTC, would be nice. Example here: /user/?selections=profile where signup is a ISO date string... whereas all the other fields where time is relevant (status.until, states.hospital_timestamp, last_action.timestamp) are all UNIX timestamps.

Pretty please, can we have some standardisation? I'll buy donuts or cake IRL.

Yours Irkedly
~ Pobk
Chedburn [1] Admin Developer · #3
Why?!!!

Quite simply, because nobody has reported them.


The types have to be manually cast, I'm happy to change them as reported, but I'm probably not going to go hunting for all of them.

I've fixed the skills selection, and I've changed the signup date to an unixtimestamp.
Chedburn [1] Admin Developer · #4
If it's an int, please return an int; example here - /user/?selections=attacks where empty string returned if there's no value - Why?!!!

For this, I'll need some more specificity please.
Hemicopter [2780600] · #6
Looking into it, it seems that a stealthed attack towards yourself leads to the "attacker_id" and the "attacker_faction" being "" instead of 0 or, what pobk would suggest, null.

A non-stealthed attack shows 0 for missing values, like "defender_faction" on a mission target, for context.
pobk [3171827] · #8
Ok. Here's quick run through of my schema validation for user and attacks section:

class AttackModel(BaseTornModel):
attacker_faction: int | str
attacker_factionname: str
attacker_id: int | str
defender_faction: int | str

There's some more in the API, I'll raise more threads to point them out as I find them.
Pops [1025410] · #9
massive changes that destroy a huge chunk of api related tools > done in 5 minutes on the fly without warning

inadequate and non functional chat system > 3 months on and still in the same non-functional state

...
pobk [3171827] · #11
WOOAAAAAHHHH You made these changes?! Live?! On a friday!?

WTH dude... What the ACTUAL rectal fingering batman!?
Chedburn [1] Admin Developer · #17
I work every day, it doesn't make a bit of difference to me.

It's becoming harder and harder to update/improve the API, even these tiny insignificant changes can cause problems. I really don't see any way to improve this process.
Chedburn [1] Admin Developer · #18
Any idea why? I don't understand what Torn PDA would be doing with these values, and how such a minor change could cause such a major problem.

For obvious reasons I can't announce this stuff in advance, nor would that likely even help. These are meant to be quick updates I can make when I have some spare time, to make the API community happy.
Flid [2594918] · #19 · edited
My suggestion would be some sort of notification process as part of the implementation plan.

A simple forum post say, a week? Ahead of time saying "these api endpoints are changing from X to Y" would be enough.

Then it's on the tool devs to react and adapt their tools.