API server load & bandwidth reduction query option

(1)::

a dated request, eg

a) https://api.torn.com/faction/?selections=donationnews&key=abc123&since=1526532280 or
b) https://api.torn.com/faction/?selections=donationnews&key=abc123&since=1526532280&small=true

it either returns API from that timestamp, or empty object (about 2-3 characters and maybe 50 bytes of protocol data)

a) https://api.torn.com/faction/?selections=donationnews&key=abc123&since=1526532280&full=true or
b) https://api.torn.com/faction/?selections=donationnews&key=abc123&since=1526532280

that could return same as API or an empty object if nothing has changed or been added since TIMESTAMP.

 

this would help cut down on outgoing bandwidth from servers, and un-needed duplicate data, which would significantly improve some data processing jobs.

With (b) pairs being just an extension to current API usage, it wont break current code that does not get updated

 

(2)::

single value responses, eg:

https://api.torn.com/faction/?selections=currency&key=abc123&single=money

would return:  {"money":1232164356}

and a single object with:

https://api.torn.com/faction/?selections=donationnews&key=abc123&object=244301587

would return:  { "donationnews": { "244301587": { "timestamp": 1526534297, "news": "Chedburn donated 100 x Vicodin to the faction" }

https://api.torn.com/faction/?selections=donationnews&key=abc123&single=timestamp&object=244301587

would return:  {  "timestamp": 1526534297 }

or maybe for better debugging:  { "donationnews": { "244301587": { "timestamp": 1526534297 } } }

 

NOTE: "returns nothing" refers to and empty API object "{}" not "no data" or "no response" from server.
Alternately a "{nc:{}}" reply may  be desired to indicate "no change" for new or changed data on the server, but it is not prefered.

Also note that a "from=&to=" could be added for querying older data

This should be in suggestions forums, without a poll though :P

I believe some selections already do have something like that but am not sure which ones. It would be pretty beneficial for all that would make use of it to have it though.

This would be very helpful, but I'm not sure about getting nothing if nothing has changed, returning from a subroutine with nothing usually means a failed download need something to work with, if you fired up your app collected info and then for some reason you lost that info and you do another call to recheck but get nothing back because its not changed, would not be helpful

I currently do a full hit list with a start date, http://prntscr.com/jkq89a, I then search the list for the start date i require and start processing the info, I always hold a backup of the last call so I can view the last, and can view the number of attacks and respect made from that date http://prntscr.com/jkqby8, this is only a quick view.

I also use the same data to fill out all the actions of every member http://prntscr.com/jkqdr8

Actually come to think of it, putting it here and taking a vote on it as if it was a suggesting isn't a bad idea: since its is API related and exposing it to the whole community is probably not a good idea. Maybe 25-50 likes to get it to dev's eyes? (Probably what we all suggest is gonna be good though).

First option seems flawed, since someone would have to store a history of what it has sent/received. And if the data was processed incorrectly (maybe in a test bench, or data loss), how would u ask the server to reset history?

um @echoblast53, I think u misunderstand how the Torn server and the API works.

U can only READ from the server via the API, not WRITE to it.

 

So what we are talking about is a 3rd party who is storing, analysing, or referencing data via API calls.

so (@LouBaker) the "nothing is returned" is actually an API response object, with nothing in it. An object that u can manipulate, with 0 children, or if the devs think wiser, a "nc" child (short for no change)

I know for a fact that TornStats have to dump alot of duplicate data, and they do thousands of API calls once a day, so that just by itself would unload ALOT of capacity on the Torn servers.

And DocTorn could poll API for sub parts of objects referenced, again releaving ALOT of capacity from the Torn servers

then there are scripts and those of us that hammer certain API objects on a per second basis, but usually what we are looking for is NEW DATA, so asking for results from the API with a time frame, and only getting results if there is indeed new data, especially if u only want sub parts of an object, has huge benefits for unloading capacity against the Torn servers, making the whole "space" faster as a result

it can also be used to verify local data against the server, not on bulk but rather of some sub sample of that bulk

hope that at least clarifies its use and intention

Paul

PS I edited the OP to better reflect concerned posts

what the op request sounds like writing to me: but not writing game data: only a few memory calls.

im writing from the perspective of "if this was to be implemented "

well considering "if this was to be implelented" you STILL will not be able to use the API to WRITE to torn servers, I really dont get ur point (nor would any others I think).

The fact is ur only grievance against this addition to the API, is based on a lack of understanding of how API works and what API can do.

At is essence API is simply and ONLY a db results query tool - ie the API can neither INSERT nor UPDATE data, so "write" has no bearing on what we are talking about here, not even implied.

BTW I have reworded the OP to clarify any possible misunderstanding (which there obviously was in this case)

oh you know what: i just realized you are sending the timestamp. (torn already has a timestamp in place... undocumented though...) i thought you are suggesting that the server was suppose to store a memory of what calls the api has retrieved, and smartly prune out duplicated calls.

so nvm, first option isnt flawed xd