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.
Related
I use POSTMAN GUI for retrieving a list of items from Shopify API.
I would like to know if there exists a way to get available product id's alone, preferably as a list of values over a single api GET call. The one I know of is
/admin/api/2022-04/products.json
It returns a list of all product information, and looping over them/traversing the json is not very efficient. I hope there must be an easy way to fetch all ID's alone in one go. Should there be not?
You can add /admin/api/2022-04/products.json?fields=id to the end of your request to limit the output only for a single field or multiply.
Please note that if you have more than 250 products you will need to make more than one request, since the request is limited to 250 products.
You can make one call to the Admin API for all your product IDs using the Bulk Query. That will result in you receiving a URL where you download a file in JSONL format with every single product ID in your store, without the paging or limits of other approaches.
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}}¤tPage=1&pageSize=200&revert=True
I'm having this use case I'm not figuring out by the soundcloud documentation page: I fetch the last 10 most recent tracks. In 2 hours, I want to see if there are new tracks. So technically, I want to ask "give me the tracks with created_at greater than the created_at of my last fetched track". How can I do that using the current Soundcloud API spec?
You can send created_at[from] parameter in the request which will allow you to set a minimum creation date for your query.
For example
/users/x/tracks.json?created_at[from]=2012-11-01%2016%3A02%3A00
For more info check the filters heading underneath each resource :)
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!
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.