Is it possible in using the Soundcloud Javascript API to order results by like count? Everything I can find says you can no longer order by 'hotness' but nothing about other sorts. I've tried adding an order parameter to my API call such as:
SC.get('/tracks', {
limit: 200,
genres: 'electronic',
order: 'likes_count'
}).then(function(tracks) {
console.log(tracks);
});
But the API call returns a 400 Bad Request, as soon as I remove the order: 'likes_count' line the API call works again.
The order parameter is no longer in the SoundCloud API.
Related
I am using Restheart and MongoDB. And I am calling one service(API) for the response data.
Working API
http://127.0.0.1:8080/test/donor?filter="{'name':'john'}"
When I calling above API then it is working, But When I putted API filter is empty, Like filter={} then it is not working.
Not Working API
http://127.0.0.1:8080/test/donor?filter="{}"
When I calling API with empty filter="{}", Then its giving me 400 Bad Request
Actually I wan to achieve one API Call for two purpose.
One for with filter condition.
Second one without filter condition.
I want to call Like below.
var qryFilter = {};
var qryFilterParam;
qryFilter["color.code"] = dateInParameter.code;
qryFilterParam = '&filter=' + JSON.stringify(qryFilter)
http://127.0.0.1:8080/test/donor?qryFilterParam
Then some time qryFilterParam have value and some time don't have. When Its have values like filter="{'name':'john'}" then it is working but when it's don't have key value like filter="{}" then it is not working. I am searching solution on website http://restheart.org/curies/1.0/filter.html but I am not able find to solution.
An empty filter is not allowed by restheart.
You need an if statement in your code to make a request with filter qparam and a request without.
I am trying to bring comments made on a particular event by targeting this URL: https://graph.facebook.com/1466384840257158/comments
I am passing the user_access_token
I have two comments at present on this event made on the same
day(2014-03-29)
Now I try to pass a date which should bring an empty data result/object
like this: https://graph.facebook.com/1466384840257158/comments?since=2011-01-01&until=2014-01-10
This request has no effect, it still shows me the two comment made
on the 29th
I have tried the same kind of date range on my user-id/feed and it
gave me an empty data object.
Finally i tried event-id/feed (before trying date filter) and it
gave me the following error
.
{
"error": {
"message": "An unexpected error has occurred. Please retry your request later.",
"type": "OAuthException",
"code": 2
}
}
Could you please guide me about date filter on that particular query (point4) or if you have any other idea to use date filter on comments made for an event.
Comments use Cursor-based Pagination, so you cannot use since or until on the comments endpoint (these parameters would work f.ex. for the feed endpoint).
To get the comments in a time range you have to fetch all comments from NOW to the start of the time range, f.ex. with https://graph.facebook.com/1466384840257158/comments?filter=stream&limit=1000+paging (the filter=stream will order the result with the timestamp).
USING SINCE UNTIL FOR COMMENTS on GROUP
If you want to use since and until for comments, it is not possible directly for a group. So, First you can apply it for status(feed) and then get the comments for that feed.
This works for me:
{group_id}/?fields=feed.since(08/25/2016).until(08/31/2016){from,comments{from,message}}
Why don't you try first to filter by notifications?... notifications allows you to add parameters like since. For example (using Facebook pages):
https://graph.facebook.com/PAGEID?fields=notifications.since(2015-3-31 00:00:00).limit(250).include_read(true)&{id,created_time,updated_time,unread,object,link}&access_token=ACCESSTOKEN
Once you got the json data, loop through data, get the ID and send a second request but this time using the PAGEID_POSTID edge. Something like this:
https://graph.facebook.com/PAGEID_POSTID/comments?fields=id,from{name,id},message,can_remove,created_time&limit=1000
Voahla!... there's no need to read every comment!...
Note 1: A Page access token is required, along with the manage_pages permission
Note 2: Use the parameter/field include_read to get all the notifications, even the already readed
Note 3: In the second request, use the parameter/field "filter=stream" to order the posts and get the comments made in the name of your page
Note 4: Don't forget to control the asynchronicity once you loop!
Note 5: Notifications duplicate posts, use an array to avoid to read more than one time the postUse the parameter/field include_read to get all the notifications, even the already readed
I do not know if it's too late. But, Yeah it works in the graph api version 3.3.
for example: if you wanna get comments on a post of a Facebook page you can do it like this:
You have to use page Access-token
The get Graph Request : post_id/comments?since=some_date
I'm using the below line:
commonService.FindAll(new Intuit.Ipp.Data.Customer(), currentPage, itemListPageSize).ToList();
When returning multiple pages the paging isn't returning the right rows on page if there are sub-customers. To reproduce, just create several customers and retrieve the second page like:
commonService.FindAll(new Intuit.Ipp.Data.Customer(), 2, itemListPageSize).ToList();
When it retrieves page 2, the first page's data is returned.
Am I doing something wrong?
FindAll with paging actually uses query endpoint.
Please mention if you are trying this call against QBD/QBO.
Can you please capture the raw request and response of the above call and share in this post.
(for that you can enable logger as mentioned in the following docs, or you can configure your app with any http snooper like Fiddler.)
https://developer.intuit.com/docs/0025_quickbooksapi/0055_devkits/0150_ipp_.net_devkit_3.0/logging
You can try this call directly using ApiExplorer. Please verify if you are getting the same result.
https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services/020_key_concepts/00300_query_operations/0100_key_topics#Pagination
Thanks
It used to be that the response from a request gave us an array of request ids (as described here http://developers.facebook.com/docs/reference/dialogs/requests/) but it seems now the response variable returns two items insead 'to' and 'request'. To being a comma delimited string of user ids and request being a request id. Is this correct? I have seen nothing about this anywhere but it is the behavior I am seeing currently.
Update
Here is a super simplified version of my call:
FB.ui({method: 'apprequests', message: 'My Great Request'}, requestCallback);
function requestCallback(response) {
for(var key in response){
console.log(key);
console.log(response[key]);
}
}
When I make a request to one person the variable response has two keys: request and to. Request is a request id, to is the id of the person I'm sending the request to. If I make a call to the graph api using the provided request id, however, I find that the user under both 'to' and 'from' are equal to the sender's name and fbid.
Alternatively, if I request to multiple people request is equal to a single request id and to is an array containing all the fbids of the users that had requests sent to them. When I make a call to the graph api, however, I once more find that both 'to' and 'from' contain the user id and name of the requesting user.
I faced similar issue yesterday. Had to fix my code. But today request_ids were back in the response. So I updated the code again. But this time to work with both type of objects.
I found the documentation here (move down to the "Performance improvements" section)
http://developers.facebook.com/blog/post/569/
But it still doesn't explains why they reverted the change today. Or was it accidently released yesterday.
As in the documentation, the new callback will receive an object (response) that contains an array (request_ids) of request ids:
{
"request_ids": [
0: [request_id]
1: [request_id]
...
]
}
So I suppose you can loop using this modified code:
function requestCallback(response) {
for( var k in response.request_ids ) {
console.log(k);
console.log(response.request_ids[k]);
}
}
There is already a bug filed here
http://developers.facebook.com/bugs/129565473812085
There is no clear information yet whether the response is really changed or its a bug.
I am requesting this page to get the events with the keyword
"conference":https://graph.facebook.com/search?q=conference&type=event
This works fine.
The problem is the pagination returned:
"paging": {
"previous":"https://graph.facebook.com/search?q=conference&type=event&limit=25&since=2010-12-18T17%3A00%3A00%2B0000",
"next":"https://graph.facebook.com/search?q=conference&type=event&limit=25&until=2010-11-04T16%3A29%3A59%2B0000"
}
It seems to have more events with "conference", but requesting these 2 pagination URLS returns no data.
It's weird because it's the same for any requested keyword, and the pagination URLs returned by the Facebook API seems to always returns empty data.
Does anyone know what's the issue?
Thanks
I encountered similar confusion with a query against places. The "next" URL behaved exactly as you described it.
I could query location information using a url like this:
https://graph.facebook.com/search?access_token=INSERT_TOKEN&type=place¢er=55.8660,-4.2715&distance=150&limit=10
And got back JSON with the first 10 places plus the following fragment which suggests the existence of paging params:
"paging": {
"next": "https://graph.facebook.com/search?access_token=INSERT_TOKEN&type=place¢er=55.8660\u00252C-4.2715&distance=150&limit=10&offset=10"
Hitting that URL doesn't work. But I did figure out a combination of limit and offset params that gave me effective paging.
limit=10 & offset not defined => first 10 results
limit=20 & offset=10 => next 10 results
limit=30 & offset=20 => next 10 results
limit=40 & offset=30 => last 8 results (can stop here because less than 10 back)
limit=50 & offset=40 => confirmation that there are no more results
I realise that I've got "limit" and "offset" rather than the "limit" and "until" params that you get, but, hopefully you could apply the same technique i.e. keep incrementing the limit and inc the date/time to that of your last result?
I think this is a standard practice in Facebook Graph API. I think if your request resulted to a non empty JSON, they will always give you the next paging, even though it might be empty.
I am however not 100% sure, because Facebook Graph API does not seem to be very well documented... (for example they said we can modify this pagination thing but did not explain clearly how to do it).
Seems facebook has changed it recently.
Here's the fix:
For a datetime returned in next and previous as
"2011-01-18T08\u00253A42\u00253A35\u00252B0000",
replace all occurrences of "\u0025" with "%" and it should work fine.
If you notice the facebook's datetime format, it is
2011-01-18T08:42:35+0000
(date accepted by strtotime C function)