splent [2088243]

Hey everyone, several fixes and smaller improvements today: 

• Added 'rarity' field ("yellow", "orange", "red" or null) to 'user' -> 'itemmarket' and 'market' -> 'itemmarket' selections
• The "item" field should now always be populated in "market' -> 'itemmarket' even if there are no listings
• Added a few more bonus filters: "Any", "Double", "Yellow", "Orange" & "Red"
• The 'torn' -> 'itemstats' will now return "0" for "owner_id" if the item is being sold anonymously on market OR if it was never used
• Fixed 'user' -> 'hof' selection from returning incorrect values for some players
• Weapon bonuses in Swagger are now sorted alphabetically (lol i know it was important to some)

 

As always, Swagger schema is updated to reflect these changes.

Important note!

We'll be closing 'market' -> 'bazaar' selection in two weeks, as it doesn't serve much purpose currently.

I know instead many would rather if we added global cache and bazaar owner information to this selection, but unfortunately, because this information is no longer visible anywhere else in Torn it needs to be removed.
However, as soon as, or, if bazaars appear somewhere else in Torn, I'll be more than happy to prioritize that and create a relatable selection ASAP.

Thanks!

splent [2088243]

Hey everyone, several fixes and smaller improvements today: 

• Added 'rarity' field ("yellow", "orange", "red" or null) to 'user' -> 'itemmarket' and 'market' -> 'itemmarket' selections
• The "item" field should now always be populated in "market' -> 'itemmarket' even if there are no listings
• Added a few more bonus filters: "Any", "Double", "Yellow", "Orange" & "Red"
• The 'torn' -> 'itemstats' will now return "0" for "owner_id" if the item is being sold anonymously on market OR if it was never used
• Fixed 'user' -> 'hof' selection from returning incorrect values for some players
• Weapon bonuses in Swagger are now sorted alphabetically (lol i know it was important to some)

 

As always, Swagger schema is updated to reflect these changes.

Important note!

We'll be closing 'market' -> 'bazaar' selection in two weeks, as it doesn't serve much purpose currently.

I know instead many would rather if we added global cache and bazaar owner information to this selection, but unfortunately, because this information is no longer visible anywhere else in Torn it needs to be removed.
However, as soon as, or, if bazaars appear somewhere else in Torn, I'll be more than happy to prioritize that and create a relatable selection ASAP.

Thanks!

splent [2088243]

Hey everyone, several fixes and smaller improvements today: 

• Added 'rarity' field ("yellow", "orange", "red" or null) to 'user' -> 'itemmarket' and 'market' -> 'itemmarket' selections
• The "item" field should now always be populated in "market' -> 'itemmarket' even if there are no listings
• Added a few more bonus filters: "Any", "Double", "Yellow", "Orange" & "Red"
• The 'torn' -> 'itemstats' will now return "0" for "owner_id" if the item is being sold anonymously on market OR if it was never used
• Fixed 'user' -> 'hof' selection from returning incorrect values for some players
• Weapon bonuses in Swagger are now sorted alphabetically (lol i know it was important to some)

 

As always, Swagger schema is updated to reflect these changes.

Important note!

We'll be closing 'market' -> 'bazaar' selection in two weeks, as it doesn't serve much purpose currently.

I know instead many would rather if we added global cache and bazaar owner information to this selection, but unfortunately, because this information is no longer visible anywhere else in Torn it needs to be removed.
However, as soon as, or, if bazaars appear somewhere else in Torn, I'll be more than happy to prioritize that and create a relatable selection ASAP.

Thanks!

Beerstein [1322136]

How you gonna call kneecapping us an improvement? Hopefully someone builds an entire addon to replace it I guess.

splent [2088243]

Hey everyone, several fixes and smaller improvements today: 

• Added 'rarity' field ("yellow", "orange", "red" or null) to 'user' -> 'itemmarket' and 'market' -> 'itemmarket' selections
• The "item" field should now always be populated in "market' -> 'itemmarket' even if there are no listings
• Added a few more bonus filters: "Any", "Double", "Yellow", "Orange" & "Red"
• The 'torn' -> 'itemstats' will now return "0" for "owner_id" if the item is being sold anonymously on market OR if it was never used
• Fixed 'user' -> 'hof' selection from returning incorrect values for some players
• Weapon bonuses in Swagger are now sorted alphabetically (lol i know it was important to some)

 

As always, Swagger schema is updated to reflect these changes.

Important note!

We'll be closing 'market' -> 'bazaar' selection in two weeks, as it doesn't serve much purpose currently.

I know instead many would rather if we added global cache and bazaar owner information to this selection, but unfortunately, because this information is no longer visible anywhere else in Torn it needs to be removed.
However, as soon as, or, if bazaars appear somewhere else in Torn, I'll be more than happy to prioritize that and create a relatable selection ASAP.

Thanks!

splent [2088243]

Hey everyone, several fixes and smaller improvements today: 

• Added 'rarity' field ("yellow", "orange", "red" or null) to 'user' -> 'itemmarket' and 'market' -> 'itemmarket' selections
• The "item" field should now always be populated in "market' -> 'itemmarket' even if there are no listings
• Added a few more bonus filters: "Any", "Double", "Yellow", "Orange" & "Red"
• The 'torn' -> 'itemstats' will now return "0" for "owner_id" if the item is being sold anonymously on market OR if it was never used
• Fixed 'user' -> 'hof' selection from returning incorrect values for some players
• Weapon bonuses in Swagger are now sorted alphabetically (lol i know it was important to some)

 

As always, Swagger schema is updated to reflect these changes.

Important note!

We'll be closing 'market' -> 'bazaar' selection in two weeks, as it doesn't serve much purpose currently.

I know instead many would rather if we added global cache and bazaar owner information to this selection, but unfortunately, because this information is no longer visible anywhere else in Torn it needs to be removed.
However, as soon as, or, if bazaars appear somewhere else in Torn, I'll be more than happy to prioritize that and create a relatable selection ASAP.

Thanks!

Kwack [2190604]

Instead of fully deleting, could you deprecate and instead just return an empty array?

 

This shouldn't break any apps (given that an empty array was already possible if none were on the market) but removes the information from the call.

CurlyBracket [2766476]

Maybe I'm being dense, but the last update seemed somewhat contradictory.  First, you say that the last update:

  

Replaced all link generation to create links and place "id" or "ids" as path parameters instead of as query parameters

 

My read of that is that you changed the code generation so that when you send back links (e.g. a next/prev link in _metadata), you will send back links that include the id as a path parameter instead of a query parameter (e.d. /v2/user/2 instead of /v2/user?id=2).

 

But the you write that:

Additionally, any selection not yet updated in API v2, won't be able to use ID in path either, so this for example:

• /v2/user/1/basic,timestamp

Will actually behave as if "ID" was not set, and will default to key owner's profile.

 

My read of this is that the v2 protocol is shifting away from using id as a path parameter, and instead using it as a query param.

 

So I just want to be clear - which is the preferred way to indicate the id in v2 - As a path param or as a query param?

CurlyBracket [2766476]

Maybe I'm being dense, but the last update seemed somewhat contradictory.  First, you say that the last update:

  

Replaced all link generation to create links and place "id" or "ids" as path parameters instead of as query parameters

 

My read of that is that you changed the code generation so that when you send back links (e.g. a next/prev link in _metadata), you will send back links that include the id as a path parameter instead of a query parameter (e.d. /v2/user/2 instead of /v2/user?id=2).

 

But the you write that:

Additionally, any selection not yet updated in API v2, won't be able to use ID in path either, so this for example:

• /v2/user/1/basic,timestamp

Will actually behave as if "ID" was not set, and will default to key owner's profile.

 

My read of this is that the v2 protocol is shifting away from using id as a path parameter, and instead using it as a query param.

 

So I just want to be clear - which is the preferred way to indicate the id in v2 - As a path param or as a query param?

splent [2088243]

Great question. I see how it could be confusing. Let me explain in a bit more detail.

So, internally, API v1 uses "ID". This "ID" is set as a path parameter, e.g. "v1/user/1".

On the other hand, API v2 internally uses a different parameter, called "id". This "id" could previously be set only as a query parameter, e.g.  "v1/user?id=1", so you're reading this first part correctly:

My read of that is that you changed the code generation so that when you send back links (e.g. a next/prev link in _metadata), you will send back links that include the id as a path parameter instead of a query parameter (e.d. /v2/user/2 instead of /v2/user?id=2).

However, previously, if you did something like "v2/faction/8500?selections=basic&id=8510", the service processing the request would cache two different ids, ID 8500 and id 8510. This also made some other things a bit harder to do. 

With the latest changes, if you make a request like this: "v2/faction/8500?selections=basic&id=8510", only one "id" is set, the 8500 one.
However, if you really prefer, you could also pass id only as a query parameter, but if the path id parameter is present, it will always override the query parameter.

--

Which brings me to this part of my previous comment: 

Additionally, any selection not yet updated in API v2, won't be able to use ID in path either, so this for example:

• /v2/user/1/basic,timestamp

Will actually behave as if "ID" was not set, and will default to key owner's profile.

API v2 selections that haven't been explicitly modified will by default fallback to API v1 response.
Because of that, and because ID is no longer being set in API v2, this means that basically all selections in API v2 that haven't been explicitly modified will behave as no "ID" in API v1 was set.
So sorry about the confusion with this comment. I sometimes forget others are not inside of my head and don't know everything I do.
I just wanted to say that selections in API v2 that have not been processed won't work properly anymore (but I'll see on Monday if I can make a quick fix for this).

 

So I just want to be clear - which is the preferred way to indicate the id in v2 - As a path param or as a query param?

Path parameter is preferred (as _metadata links show), but you're free to use "id" as query parameter if you desire. I want the API v2 to be flexible so it's easier for others to work with it.

Hopefully this shines some light on how everything works. 

Let me know if I should explain more.

Thanks!

 

splent [2088243]

Hey everyone,

 

It seems that this change was a point of confusion: 

Additionally, any selection not yet updated in API v2, won't be able to use ID in path either, so this for example:

• /v2/user/1/basic,timestamp

Will actually behave as if "ID" was not set, and will default to key owner's profile.

Same will happen with other selections that have not been updated in v2 yet, so you'll need to use v1 for them.

so I've added some additional logic to fix this, and now these endpoints will be working again as before:

https://api.torn.com/v2/user/1/profile,timestamp?key= 

My bad there, I probably could've done this right away, but I missed it would cause so many issues even with being announced upfront.

Thanks for understanding!

splent [2088243]

Hey everyone,

 

It seems that this change was a point of confusion: 

Additionally, any selection not yet updated in API v2, won't be able to use ID in path either, so this for example:

• /v2/user/1/basic,timestamp

Will actually behave as if "ID" was not set, and will default to key owner's profile.

Same will happen with other selections that have not been updated in v2 yet, so you'll need to use v1 for them.

so I've added some additional logic to fix this, and now these endpoints will be working again as before:

https://api.torn.com/v2/user/1/profile,timestamp?key= 

My bad there, I probably could've done this right away, but I missed it would cause so many issues even with being announced upfront.

Thanks for understanding!

Skeletron [318855]

Hello splent,

 

Does this change /v2/user/{crimeId}/crimes

 

I'm getting error 17.

 

Thanks

jtower [2287159]

https://api.torn.com/v2/market/2?selections=itemmarket&limit=1&key=

 

The "limit" attribute here should limit the listings to just 1 item, but it seems it does not have effects here.

 

It works for other things, like https://api.torn.com/v2/market/?selections=pointsmarket&limit=2&key=

 

I'm assuming it's because the listings attribute is nested? But i just wanted to let you know.

 

 

 

BTW, is this the right place for v2 api bugs or should we open a new thread in the bug section? I'll create a new thread, if this doesn't belong here.

jtower [2287159]

If it's not a bug the fact that the limit attribute does not work for the itemmarket selection, then it should be a bug the fact the it works for pointsmarket? lol

 

Anyway, the limit attribute works for v1. Is it something that it's going to be implemented in v2 as well?