used the following URL to get the topicid and details for auto generated channel. But its returning empty.
https://www.googleapis.com/youtube/v3/channels?part=topicDetails&id=HC7Dr1BKwqctY&key={YOUR_API_KEY}
Does somebody know how to get the topic details from above url. your help is highly appreciated. Thanks in advance
Ignore my comment on the question above; getting topic IDs from autogenerated channels works just fine in most cases, using the endpoint you've already listed; for example,
https://www.googleapis.com/youtube/v3/channels?part=topicDetails&id=HCGV1V7wpRMrY&key={YOUR_KEY}
https://www.googleapis.com/youtube/v3/channels?part=topicDetails&id=HCAh3LGI6q4g0&key={YOUR_KEY}
Both display the topicId as you would expect ... and I guess, if you really think about it, there's no reason it shouldn't, as the autogenerated channel uses the topicID to decide what videos make up the channel! So the real question is why this particular auto-generated channel isn't returning any topic details -- Freebase does have an ID for "sports," after all. It might be worth filing a bug noting that particular channel so the engineers can look into why it's not properly reporting what topicID it was based on.
Related
I am trying to retrieve a comment on a video by comment ID using the youtube v3 data api.
Here's the documentation part I am concerned with: https://developers.google.com/youtube/v3/docs/comments#resource
In the resource documentation, there's a property called "videoId" that I don't get when using this API call:
https://www.googleapis.com/youtube/v3/comments?part=snippet,id&key={YOUR_KEY_HERE}&id=z13cdfiygorrst1f422fuzi5eqevcdwsf
Edit: I have already been trying working around this problem to no avail, also started an issue on google issue tracker to no answer. As far as I know, the youtube-data-api tag is where the developers track the issues in the API.
I am not sure why the comments endpoint does not return the videoId, but the commentThreads does.
So calling https://www.googleapis.com/youtube/v3/commentThreads?part=snippet,id&key={YOUR_KEY_HERE}&id=z13cdfiygorrst1f422fuzi5eqevcdwsf and parsing the result to get the proper comment in the comment threads (that includes replies) seems like a reasonable workaround...
I have a problem with commentThread API call. Here is one specific case: comment id: z13ocxipdz3hwxqqe04cgbuadtmnhhmybyc0k
https://www.googleapis.com/youtube/v3/commentThreads?id=z13ocxipdz3hwxqqe04cgbuadtmnhhmybyc0k&part=snippet%2C+replies&key={YOUR_DEVELOPER_KEY}&alt=json&order=time
There are 44 replies for now.
But if you use video_id (not comment id like we did above. Link: https://www.googleapis.com/youtube/v3/commentThreads?videoId=Ui-ulCWmpOU&maxResults=100&pageToken=ChYQp7fipbfsxgIYkNGqiobjxQIgACgDEhQIABCQ0aqKhuPFAhiMqqKive-5AhgCIKwC&part=snippet%2C+replies&key={YOUR_DEVELOPER_KEY}&alt=json&order=time) and come across the comment (you may have to use pageToken to iterate over pages) you will see this:
(Screenshot: https://www.dropbox.com/s/d4bf9tk51eaw7dr/Screenshot%202015-07-21%2021.08.31.png?dl=0)
As you noticed; there is 39 replies (comments) which is not true. And even if we have replies; there is no replies section. Am I missing something?
Two questions: Why number of replies don't match? Why that commentThread doesn't have replies even it has 39 replies?
Notes: As part I am using 'snippet, replies'. I don't get any API error (like throttle or limit violation)
From the commentThreads documentation:
The commentThread resource does not necessarily contain all replies to
a comment, and you need to use the comments.list method if you want to
retrieve all replies for a particular comment.
Use the comments.list call instead and specify the commentThread's ID for the parentId.
When I do the following call:
https://www.googleapis.com/youtube/v3/comments?part=snippet,id&parentId=z13ocxipdz3hwxqqe04cgbuadtmnhhmybyc0k&key=[API_KEY_HERE]&order=time&maxResults=50
I get all (44) of the responses to the comment thread you mentioned.
To address your questions:
Why number of replies don't match?
If I had to guess, I'd say it might be due to how the API differentiates between comments and comment threads (where it considers replies to other replies in a thread as opposed to them being associated with the video itself). Since the documentation says that the commentThread resource might not contain all replies to a comment, I think this is still working as intended. At any rate, in the future it's generally better to just go with the higher number of replies reported, since it's more likely that the API is missing some results than reporting extra results. Also, remember that you should be using comments.list if you want all of the replies to a certain comment thread.
Why that commentThread doesn't have replies even it has 39 replies?
To be honest, I'm not sure if it's a YouTube thing or a G+ thing. When I looked at some of the other comment threads that had replies, I was able to see them via the API call when video ID is specified. However, as Daniel mentioned, you can't actually see the replies for the thread you specified on the video itself (but you can see them when you go to that user's G+ page). It's possible that user did something to their G+ settings regarding comments on their shared posts, which is why they aren't showing up on the video itself and thus not showing up in the commentThreads list request. It's hard to say unless you talked to someone who's familiar with G+/YouTube integration.
While I wasn't able to answer your questions definitely, I was able to find some useful info that may give you some clarity and direction.
With regard to the specific case outlined in your question: the user "authorDisplayName": "Tammy L." commented on the video "videoId": "Ui-ulCWmpOU" on 11/16/2013, and received replies between 11/16/2013 and 11/18/2013. According to Tammy L.'s record on Google+, there are 44 replies to her initial comment from this date:
Although, according to the record on YouTube, it appears that there are 42 replies to her comment, which doesn't match either value returned from your API calls. Even more bizarre, Google won't display the comments when I click on "View all 42 replies":
It seems that the commentId call provides the correct number of replies made to Tammy L.'s initial comment, which is consistent with the number of replies shown on her Google+ account. Perhaps the issues with the videoId call (including the fact that this call doesn't provide replies) are attributable to the changes Google implemented around the time that Tammy L. made her initial comment (November 2013), although I'm not totally sure.
It seems that there should be a way to do youtube.com/user/{channel id} . but I can't figure it out. I also have the GooglePlusUserId (when available) to use.
Since channel URLs aren't returned in any of the parts of the channels resource, your best bet is to construct it yourself as http://www.youtube.com/channel/UC..., where UC... is the channel id.
I'd think that would be fairly future-proof.
Edit: I hear that YouTube.com URLs might get added to v3 responses at some point in the near future, and if they do, I'd obviously recommend using that instead of constructing them manually. I'll try to remember to update this answer if they are, but you can follow https://developers.google.com/youtube/v3/revision_history to check as well.
I'm trying to figure out if it's possible to get a gdata feed for an auto-generated youtube channel, aka a "Topic."
For example, here's the JPop Channel:
http://www.youtube.com/channel/HC9BkB0bbvR-4
Were this a user, I know I could get a feed like: http:// gdata.youtube.com/feeds/base/users/{username}/uploads. But since it's not a user, that doesn't work.
I know I could do a search like: http:// gdata.youtube.com/feeds/api/videos?v=2&q=jpop, but that's not exactly the same thing.
This question was asked before on the old Youtube Developer Forum, but at the time it wasn't available.
I've looked all through the API docs to see if that's changed, but can't find any reference to it.
I was hoping someone here might know if it's changed, and the docs haven't been updated, or if there's an expected ETA for that feature?
You can interact with auto-generated topic channels (those that begin with HC) by subscribing to them like any other channel.
If you just want to get a list of videos associated with the channel, though, you need to use the forthcoming v3 of the API, and you can do a search based on the underlying topic. You can get the topic id(s) related to a given channel using channels.list(id=CHANNEL_ID):
https://developers.google.com/apis-explorer/#p/youtube/v3/youtube.channels.list?part=topicDetails&id=HC9BkB0bbvR-4
(v3 isn't publicly released as of right now, so you need to use the Google APIs Explorer.)
That returns (Freebase) topic id /m/025g__, which you can then use to do a search.list(topicId=TOPIC_ID, q=BLAH, type=video)
https://developers.google.com/apis-explorer/#p/youtube/v3/youtube.search.list?part=snippet&type=video&q=j+pop&topicId=%252Fm%252F025g__
Unfortunately, you can't do a search that just specifies a topicId= without a q= right now in v3, but that's a bug that will hopefully be fixed soon. So you do need to specify something meaningful for the q= parameter for the time being, and I'm just using j pop.
My latest Twitter status update has the URL http://twitter.com/dinomite/status/1743967905 Does anyone know if there is any rhyme or reason behind the number 1743967905? It looks to me as though it might be a sequentially-assigned number for all Twitter users; I certainly haven't update 1.7b times, but all of Twitter might be around that. Anyone know?
According to the Twitter API docs it is the numerical ID of the status. I'd guess it's unique and sequential across all users, but I don't know for sure. If you need to know more take a look here for the official docs.
That would probably be the primary key in the status table. That URL format is used to look at a specific tweet.
Note that http://twitter.com/dinomite is the actual feed.
Also, based on how it seems to grow incrementally, this is probably an IDENTITY column or similar.
Yes, they're sequential.
One of the things it's helpful for is when writing a Twitter client, you can ask for anything newer than the last number you're already seen, so that you don't get and have to parse duplicates.