how do you reverse the data given from a REST API response? - cumulocity

I'm trying to read measurement data, and I get a large amount of data back. I can narrow down the items per page and get the last page, but is there a way to reverse the data so I get the most recent measurement POST?
For example, I to a:
GET: {{url}}/measurement/measurements?dateTo={{dateTo}}&dateFrom={{dateFrom}}&source={{deviceId}}
And I get get 100's of pages back, the list beginning from the first measurement. I want the last measurement first.

I found the answer, add revert=True
i.e.:
{{url}}/measurement/measurements?dateTo={{dateTo}}&dateFrom={{dateFrom}}&source={{deviceId}}&currentPage=1&pageSize=200&revert=True

Related

Restriction on retrieving file information from a folder

I am trying to get information about files in a folder using https://apis.live.net/v5.0/folderid/files?
This particular folder of mine has around 5200 files. So I am getting a readtimeout when I make the above mentioned request. Is there any restriction on the number of files that I can make the request.
Note : I am able to successfully retrieve the file information from folder if I restrict the file count to 500 say https://apis.live.net/v5.0/folderid/files?limit=500
In general it's good to page queries that could potentially return a large number of requests. You could try using the limit query parameter in combination with the offset query parameter to read sets of the children at a time and see if that works better for you.
I'll quote in the relevant information from the documentation for ease of reference:
Specify the first item to get by setting the offset parameter in the preceding code to the index of the first item that you want to get. For example, to get two items starting with the third item, use FOLDER_ID/files?limit=2&offset=3.
Note In the JavaScript Object Notation (JSON)-formatted object that's returned, you can look in the paging object for the previous and next structures, if they apply, to get the offset and limit parameter values of the previous and next entries, if they exist.
You may also want to consider swapping to the new API, which has it's own paging model (using the next links).

User's history and pagination with Deezer APIs

if I try to get the streaming history of a user, e.g.
http://api.deezer.com/2.0/user/.../history?access_token=...
I get the first result page but I don't see any method/parameter (like next, page, ...) to see the rest of the results.
How can I get the following result pages?
Thanks.
There are two parameters available to control the paging of data:
limit: the number of individual track objects that are returned in the request.
index: the individual track objects at the specified index that is the first result of the request to be returned.
Please, compare these two requests to get a better understanding of the paging system:
http://api.deezer.com/user/YOUR_USER_ID/history?access_token=YOUR_ACCESS_TOKEN&index=0&limit=10 will return the 10 latest tracks you listened to.
http://api.deezer.com/user/YOUR_USER_ID/history?access_token=YOUR_ACCESS_TOKEN&index=4&limit=5 will return the 5 tracks before the 5 latest tracks you listened to.
For your information, you cannot return more than 50 individual objects per page.

facebook shares count not accurate

may i know why this three urls return difference of count?
https://www.facebook.com/plugins/like.php?href=http://www.rotikaya.com/iqram-dinzly-tinggalkan-jalan-jalan-cari-makan-kerana-takut-gemuk/&layout=standard&show_faces=false&width=300&action=like&colorscheme=light&height=30
https://graph.facebook.com/?id=http://www.rotikaya.com/iqram-dinzly-tinggalkan-jalan-jalan-cari-makan-kerana-takut-gemuk/
http://api.facebook.com/restserver.php?method=links.getStats&format=json&urls=http://www.rotikaya.com/iqram-dinzly-tinggalkan-jalan-jalan-cari-makan-kerana-takut-gemuk/
(deprecated but more accurate)
The Graph link is intended to reflect the number a like button would show, which is an combination of several metrics.
The getStats endpoint does a more detailed breakdown. If you look at the total value on it, you'll see they match up.
https://graph.facebook.com/?id=http://www.imdb.com/title/tt0117500/
This displays total of likes and the deprecated shares as a whole
http://api.facebook.com/restserver.php?method=links.getStats&format=json&urls=http://www.imdb.com/title/tt0117500/
This one displays all the data, as you can see if you add the like count and share count it is just the same with the previous URL

Dealing with gaps in timeline

I'm looking for some assistance to sort out the logic for how I am going to deal with gaps in a feed timeline, pretty much like what you would see in various Twitter clients. I am not creating a Twitter client, however, so it won't be specific to that API. I'm using our own API, so I can possibly make some changes to the API as well to accomodate for this.
I'm saving each feed item in Core Data. For persistance, I'd like to keep the feed items around. Let's say I fetch 50 feed items from my server. The next time the user launches the app, I do a request for the latest feed items and I am returned with 50 feed items and do a fetch to display the feed items in a table view.
Enough time may have passed between the two server requests that a time gap exists between the two sets of feed items.
50 new feed items (request 2)
----- gap ------
50 older feed items (request 1)
* end of items in core data - just load more *
I keep track of whether a gap exists by comparing the oldest timestamp for the feed items in request 2 with the newest timestamp in set of feed items from request 1. If the oldest timestamp from request 2 is greater then the newest timestamp from request 1 I can assume that a gap exists and I should display a cell with a button to load 50 more. If the oldest timestamp from request 2 is less than or equal to the newest timestamp from request 1 the gap has been filled and there's no need to display the loader.
My first issue is the entire logic surrounding keeping track of whether or not to display the "Load more" cell. How would I know where to display this gap? Do I store it as the same NSManagedObject entity as my feed items with an extra bool + a timestamp that lies in between the two above and then change the UI accordingly? Would there be another, better solution here?
My second issue is related to multiple gaps:
50 new feed items
----- gap ------
174 older feed items
----- gap ------
53 older feed items
* end of items in core data - just load more *
I suppose it would help in this case to go with an NSManagedObject entity so I can just do regular fetches in my Core Data and if they show up amongst the objects, then display them as loading cells and remove them accordingly (if gaps no longer exist between any sets of gaps).
I'd ultimately want to wipe the objects after a certain time has passed as the user probably wouldn't go back in time that long and if they do I can always fetch them from my server if needed.
Any experiences and advice anybody has with this subject is be greatly appreciated!

What exactly does 'since_id' and 'max_id' mean in the Twitter API

I've been poring over the Twitter docs for some time now, and I've hit a wall how to get stats for growth of followers over a period of time / count of tweets over a period of time...
I want to understand from the community what does since_id and max_id and count mean in the Twitter API.
I've been following this page https://developer.twitter.com/en/docs/tweets/timelines/api-reference/get-statuses-user_timeline
I'm trying to get stats for a user --
counts of tweets in a particular time period
count of followers over a particular time period
count of retweets
I'd like some help forming querystrings for the above..
Thanks..
since_id and max_id are both very simple parameters you can use to limit what you get back from the API. From the docs:
since_id - Returns results with an
ID greater than (that is, more recent
than) the specified ID. There are
limits to the number of Tweets which
can be accessed through the API. If
the limit of Tweets has occured since
the since_id, the since_id will be
forced to the oldest ID available.
max_id - Returns results with an ID
less than (that is, older than) or
equal to the specified ID.
So, if you have a given tweet ID, you can search for older or newer tweets by using these two parameters.
count is even simpler -- it specifies a maximum number of tweets you want to get back, up to 200.
Unfortunately the API will not give you back exactly what you want -- you cannot specify a date/time when querying user_timeline -- although you can specify one when using the search API. Anyway, if you need to use user_timeline, then you will need to poll the API, gathering up tweets, figuring out if they match the parameters you desire, and then calculating your stats accordingly.
The max_id = top of tweets id list .
since_id = bottom of tweets id list .
for more : get a deep look in the last diagram .. here
The max_id and since_id are used to prevent redundancy in the case of Twitter API calls. Visualize the tweets coming in as piling onto a stack. One API call has to specify how many (count) tweets will be processed. But as this call is made, new tweets may be added. In that case, if you draw out a stack and run through the process, you notice that there can be some 'fragmentation' or sections of unprocessed tweets stuck in between processed ones. This is visible in below image as well.
To get around this problem, two parameters are used to keep track of the latest/greatest ID tweet previously processed (since_id) and the oldest/lowest ID tweet recently processed (max_id). The since_id points to the bottom of the 'fragment' and the (max_id-1) points to the top of the 'fragment'. (Note that the max_id is inclusive unlike the since_id)
So, the parameters together keep track of which part of the tweet stack still needs to be processed.