Situation:
Imagine two models: Songs and Playlists
You can add reactions (verbs, e.g. "like", "dislike", etc.) only to Songs.
Each Song lists its aggregated verbs, e.g. 2 users liked the Song, 4 disliked it.
I set up two feed groups: Song_flat (flat) and Song_aggregated (aggregated)
Verbs are added to Song_flat while Song_aggregated follows Song_flat.
So far that works fine incl. realtime updates.
Challenge:
Playlists should display an aggregated view (again by verb) across all the Songs in this Playlist.
I set up two feed groups: Playlist_flat (flat) and Playlist_aggregated (aggregated)
Playlist_flat follows all of the Song_flat feeds associated to it. Playlist_aggregated follows Playlist_flat.
So in total: Playlist_aggregated follows Playlist_flat follows lots of Song_flat feeds.
I need the intermediate Playlist_flat feed in order to consume real time updates of all the Song_flat changes which the Playlist_aggregated feed cannot provide.
Issue: While Playlist_flat lists the verbs added to its songs immediately, Playlist_aggregated does not contain any verbs despite Playlist_aggregated following Playlist_flat.
Questions:
Is it an error in getstream or are verbs not propagated via 2 link followerships?
So, must I require Playlist_aggregated to follow directly the Song_flat feeds and NOT via Playlist_flat?
Thank you.
Manuel
Feed updates are propagated to followers only to direct followers; 2nd or higher degree follower feeds (eg. follower of a follower) are not supported. My suggestion is to let an aggregate playlist follow each song (or add activities to the song feed and target the playlist with the to targeting field)
Related
I'm designing an API and I want to heed RESTful approaches.
Because in my research most similar articles refered to players and teams I'll stick to it.
In this case a player can have more than a team at a time but has to have at least one.
You cannot delete a player if the player ist attached to more than one team.
For that if you want to create a player you need to:
POST /teams/{id}/players
A direct
POST /players
wouldn't take into account that the player has a team so it is not allowed.
If you want to delete a Player you could do:
DELETE /players/{id}
This should only be possible if the player is only attached to one team, but should be refused if the player is in more than one team (for that case you need to dissolve all links to teams except one).
Now I've different approaches to handle creating and removing new Links between Teams and Players:
POST /teams/{id}/players/{id}
PUT /teams/{id}/players/{id}
POST /players-teams (with players_id and teams_id in body)
a. DELETE /teams/{id}/players/{id}
b. DELETE /players-teams/{id}
Some thoughts at the different solutions:
ad 1. GET wouldn't reference the same information
ad 2. I don't provide the id of the relation...
ad 3. should I provide GET /teams/{id}/players-teams and GET /players/{id}/players-teams - or GET /players/{id}/teams-players
ad a. Wouldn't that delete the player?
ad b. who would know the id of the relation?
Given that a player can exist in multiple teams, and the team-player relationship might change, I think it's common to have 2 separate namespaces for this:
players/ <- list of all players
players/{id} <- a single player
teams/ <- list of all teams
teams/{id} <- a single team
The thing that's missing from this is the relationship between team and player. A good way to handle this might be to have players represented as links on the team. A fictional representation of such a team resource:
{
name: "team awesome",
_links: {
self : { href: "/teams/A" },
players: [
{ href: "/players/1" },
{ href: "/players/2" },
]
}
}
If relationships are represented as links on the team resource, the act of removing or adding players to a team is the same as sending a PUT resource to the team and adding/remove these links. The above format uses HAL.
But what if you want to just get a full list of players + their information? It's definitely possible to represent 'all players on a team' as a separate resource, maybe on:
/teams/{id}/players
I would still make sure that all the players in this resource link to /players/{id} and not /team/{id}/players/{id}.
Even though it's not disallowed for a single entity to appear on multiple urls in the system, this might get confusing for a user because it might look like they are separate resources.
If you go to business manager of facebook, then go to the "All Audiences", then under the "Audiences" tab, you will see a "Filters" button right beside the "Create Audience" button. Now my question is, which part the json data being provided by the facebook apis should I based the data that I should pull out based from these filters ?
- Recently Used
- In Active Adverts
- Action Needed
- Shared
Because unlike the "ready" and "not ready" status, those four filters that I mentioned are not straight forward where I can just look for the numbers from the returned json data. so how ?
Most likely, not all of this information is available through the API.
However, if you take a look at the following doc, you can see some reelvant fields that may help:
https://developers.facebook.com/docs/marketing-api/reference/custom-audience
Most likely you can use the field operation_status to look at whether an audience needs action.
For whether it's shared, take a look ad the edge adaccounts which will let you see the ad accounts this audience has been shared with.
For recently used, you'll probably have to look at the edge ads and review the status of the ads.
To save having to make multiple requests, you can take a look at field expansion in the Graph API, which will let you query for fields of objects in results using a single request:
https://developers.facebook.com/docs/graph-api/using-graph-api#fieldexpansion
Is there a way to load multiple adinterests by IDs in a single API call?
Here's situation:
We have multiple adinterests for ads targeting campaign. For example, we are targeting users that are interested in:
music (ID=111)
arts (ID=222)
museums (ID=333)
We are listing all interests to a user, but in the database we store only IDs.
Currently we can only load single interest per request, e.g.:
https://graph.facebook.com/v2.3/111?access_token=___
https://graph.facebook.com/v2.3/222?access_token=___
https://graph.facebook.com/v2.3/333?access_token=___
or
https://graph.facebook.com/v2.3/?access_token=___&type=adinterest&id=111
This works. However, I would like to load all interests in a single call to speed up page load, for example:
https://graph.facebook.com/v2.3/?type=adinterest&id[0]=111&id[1]=222&id[2]=333&access_token=___
This, unfortunatelly, does not work.
So, is there any way to load ad interests list by list of supplied IDs?
You can use the Batch request framework to make a single HTTP request to multiple endpoints. See
https://developers.facebook.com/docs/marketing-api/batch-requests
I am fetching a list of tracks from soundcloud's API using the following query to retrieve the 5 most popular tracks:
https://api.soundcloud.com/tracks?client_id=XXX&order=hotness&limit=5
But recently SoundCloud removed the hotness order. In the blog post they say tracks can instead be sorted by playback_count. But can this be done in the query or do they suggest I pull down the whole SoundCloud library and order them in the client? The following doesn't seem to work:
https://api.soundcloud.com/tracks?client_id=XXX&order=playback_count&limit=5
So how would one retrieve the top tracks on SoundCloud?
The solution was to use the undocumented calls for the explorer feature that SoundCloud itself uses (I used the dev tools in Chrome to check the AJAX calls).
https://api.soundcloud.com/explore/sounds/category?limit=L&client_id=XXX
This appears to use some sort of sorting on the popularity of the songs. The songs can then be filtered on only music by checking the "grouping" attribute. I then have to resolve the list of IDs to actual songs which can be done with the (documented, official) API call:
https://api.soundcloud.com/tracks?ids=1,2,3&client_id=XXX
This seems to work perfectly and I also get the added benefit of an even distribution among genres. But of course, this can stop working at any moment since the API calls are undocumented and perhaps not meant for public use.
Just wanted to provide an update. It seems soundcloud has moved to v2 of the explore API call.
Use this to get a list of categories:
https://api.soundcloud.com/explore/v2
And this to get tracks from a category:
https://api-v2.soundcloud.com/explore/metal?limit=10&offset=0
So far it seems to without a key, although I have no idea how long that will last.
EDIT: So the 2nd url doesn't seem to allow cross-origin, but so far this does work, though it only returns the trackID not the full information
https://api.soundcloud.com/explore/v2/metal?limit=50&consumer_key=XXX
check here, soundcloud removed order by hotness.
Has order by hotness been removed from Soundclouds API
so, for now, only order by date is possible.
Is there a method in the API to query the number of subscribers for one of the new profiles? I am talking about the new profiles (not pages), like this one for Tyra Banks:
http://www.facebook.com/XOXOTYTY
I can see on that page that she has 696k subscribers (more specifically, 696,833 as it shows when you search for her profile), but I cannot find that number in the graph.
I know that /userId/subscribers gives a list of my subscribers (which is awesome), but many pages that I'm querying have over 10k subscribers, so it doesn't list them all, and I just need the count.
Only user object have subscribers connection.
For page you can get count of "fans" by looking for likes property.
Update:
If you're looking for subscribers count on user object you need to use paging to get all the list, since there is no way to get only count of this data (currently, I hope this will be added later, since it's a really in high-demand by some players)...
Yet now you're out of luck since there is a BUG #134805496634011 with paging, so you may only get first page. There is limit argument but it's can't be whooping 697k for sure...