Quick question - as stated in the title. Is that possible? I thought the following endpoint would be my best shot: https://developers.google.com/youtube/v3/docs/comments/update, but can't find anything that resembles api call for rating a video, nor did I find any documentation on that for v3
If it is, please point me to the http endpoint.
Partially Yes, You can use that endpoint and specify a value for snippet.viewerRating but as of now it only allows you to specify two values like and none.
The rating the viewer has given to this comment. Note that this property does not currently identify dislike ratings, though this behavior is subject to change. In the meantime, the property value is like if the viewer has rated the comment positively. The value is none in all other cases, including the user having given the comment a negative rating or not having rated the comment.
Related
Since today (or yesterday) the Google Place Autocomplete web service (https://developers.google.com/places/web-service/autocomplete) is returning a wrong place id (place_id). Does anyone know how to get the right place id from the Autocomplete API?
For example, the place id for New York City is ChIJOwg_06VPwokRYv534QaPC8g (according to the Place Details API), but the Autocomplete API returns ChIJOwg_06VPwokRYv534QaPC8iaBilOZXcgWW9yayBDaXR5LCBOZXcgWW9yaywgVmVyZW5pZ2RlIFN0YXRlbg as place_id. The beginning of the string is almost the same, except for the last character of the 'right' place id (g).
Is this a bug or is Google changing their place ids? Unfortunately I can't find anything related to this problem.
Some place ids from the Place Autocomplete API have been altered due to a recent issue: https://code.google.com/p/gmaps-api-issues/issues/detail?id=11107. The longer place ids should be accepted by all Maps APIs (but see the caveat in https://code.google.com/p/gmaps-api-issues/issues/detail?id=11107#c30).
Unfortunately, this will be around for some time. A way to get the "short" place id corresponding to a long one is to issue a Place Details call with the long place id (the returned result will have a short place id).
While it would seem to be a bug, it's always been true that LinkedIn's r_basicprofile API permission only returns the user's current positions, while r_fullprofile returns current and past positions. But with today's announcement that r_fullprofile will require enrollment in LinkedIn's partnership integration program, this difference has a real consequence: Many LinkedIn-integrated sites will no longer be able to get past positions.
My question is to LinkedIn API folks: Is it deliberate that past positions are not returned for r_basicprofile requests? Hopefully not, and hopefully this could be fixed. Alternatively, three_past_positions could be enabled for r_basicprofile... That'd give us something to work with.
If everything is working as intended, and no changes will be forthcoming, how difficult will it be to join the partnership program? Do you foresee many companies and start-ups being able to join?
Thanks!
I think that #JoseR answer was extremely close... the part that was missed was that of within the 'field' description it states:
positions -> An object representing the member's current position
https://developer.linkedin.com/docs/fields/basic-profile
so, if the member has ten 'current' positions, it will return ten, but if they only have one, then just one is returned... so, to get the r_fullprofile is your next best option (with application of course)
As we can see in https://developer.linkedin.com/docs/fields/basic-profile is supposed that now in the basic profile we are going to get all the positions, at least it does not say anything about any restriction to the current ones.
But please I'm +1 in this question. It would be good to have some confirmation from the linkedIn staff that, when accessing the new API, we are going to get all the positions.
Thank you.
I'm trying to get one good photo result on the Foursquare API which are representative of a venue.
Currently I'm using:
https://api.foursquare.com/v2/venues/VENUE_ID/photos?group=venue&limit=1
This works, but it appears that the photo filtered is always the most recently added photo for that venue, which is not necessarily always the best. There also doesn't seem to be anyway to any sort differently (by rating etc.). I would prefer that the photo that appears be always the first photo result on the foursquare website for the venue, whatever that may be.
I was playing around with the suffix, and I found that if instead of
photos?group=venue&limit=1
I just put
photos?&limit=1
I would get the results I am looking for (the first photo that appears on the website for that venue). However, on the documentation it says that having a group value is required. Obviously, I don't want to set behavior based on a bug, but it works.
So, is it a bug? Or is it just a problem with the documentation that says group is required. Any help would be appreciated.
Thanks!
That's probably a bug you're encountering, but to get the first photo on the venue page, you can query the venues detail endpoint and then use the photo object in the venue result: https://developer.foursquare.com/docs/explore#req=venues/40a55d80f964a52020f31ee3
Can someone explain to me in, in REST terms, Twitter's design decision with the parameter placement in these two calls? It seems that the :id placement is inconsistent and arbitrary (although clearly this was deliberate).
GET statuses/:id/retweeted_by
Show user objects of up to 100 members who retweeted the status.
GET statuses/retweets/:id
Returns up to 100 of the first retweets of a given tweet.
There are other similar examples throughout their API (https://dev.twitter.com/docs/api), so I'm definitely missing something.
Thanks!
Just making guesses here
Someone at Twitter once pointed out that the Twitter API runs on several servlets. I can only assume that this was related - it's easier to map /retweets/* than to map every single combination.
Update: I think that the history of the API itself can also be relevant. Twitter's API hasn't really changed much over the past years, and if it did change then it would be because new features would be added. An endpoint like GET statuses/show/:id is old, while GET statuses/retweets/:id is newer. If Twitter at some point decided to change naming conventions, they couldn't just rename the old ones, since it would break applications.
Another theory of mine is that GET statuses/retweets/:id actually doesn't refer to the Tweet :id itself, but is about the tweets that were based on it. GET statuses/:id/retweeted_by is directly related to the tweet itself, by returning users and not other statuses.
I too am often puzzled by the naming consistency. I'm sure they have their reasons though.
I ended up checking with a friend at Twitter, who says:
"I just talked with the guy who originally wrote those two API
endpoints, and he doesn't remember why. To answer your question,
though, there probably isn't a good RESTful reason for that design."
My question pretty much says it all: I'm looking for a way to display Amazon Marketplace listings based on an item lookup. Example: If I do a call to ItemLookup with an ASIN of 0590353403 (Harry Potter and the Sorcerer's Stone), I'm looking for a result set of perhaps the top ten new or used Marketplace listings, preferably with seller information attached.
I apologize if this is clearly documented somewhere, but I have been looking all through the Amazon API docs and on Google to no avail. StackOverflow doesn't seem to have any Related Questions that match what I'm asking, either.
Thanks in advance!
After some further research, it seems I've found what I was looking for. In order to get a listing of all sale offers -- not just those from Amazon itself -- you must specify the MerchantId parameter in your query to the web service. This parameter can take on a few different values: "Amazon" (default), "All," "Featured," or a specific Merchant ID.
To get all the offer information, including seller names and the like, you must also submit the parameter ResponseGroup with the value "OfferFull."
Hope this helps somebody else out down the line! :-)