So. According to the pending March 6th changes, I have question regarding the "Removing apps from /me/accounts/ and page_admin FQL table" change.
This change seems, to me, imply that you are also going to remove "/<user_id>/accounts/" - is this the case?
Because I'm using "/<user_id>/accounts/" to get non-expiring access tokens (c.f. https://developers.facebook.com/roadmap/offline-access-removal/#page_access_token).
Cheers!
Tomage
Note that the roadmaps states they will "longer show apps under /me/accounts/". The endpoint, with access to Pages, will still be there. Just the apps that are currently in that list will not be. If you want to get the apps they are a developer of, the docs state " hit /me/applications/developer/ or use the app_role FQL table."
https://developers.facebook.com/blog/post/2013/02/27/platform-updates--operation-developer-love/
Related
About a year ago, google maps added the "Located In" feature to places, so if a certain business in located inside another business its listing will show the relation.
This means that if a restaurant for example, is located inside a shopping mall, it will be stated that it is inside.
This means that google keep some kind of relation between places and "sub places" and I was looking for a way to query all places that are inside another place.
For example, If I want to go to a mall, and get all restaurants inside the mall.
I've read the google Places API, and it seems that the "near by" search is based mainly on point(long,lat) and radius, but I could not find a way to query by "located in" businesses.
If anyone is familiar with such a feature, I'd appreciate any help with that.
Unfortunately Places API doesn't support this functionality. I can see that similar issue was created in Google issue tracker 2 years ago:
Bug: Places located inside another (mall, shopping centre) does not show up in results
However it looks like Google rejected it for some reason. I would suggest filing a new issue in Google issue tracker:
https://issuetracker.google.com/issues/new?component=188872&template=789006
Hopefully Google replies something soon.
Since LinkedIn support has moved to StackOverflow... here we go. It might seem like a stupid question though...
The LinkedIn API will move to v2 in the near future, but I am unsure which data will really remain available (without being a LinkedIn Partner).
I have been reading the API v2 documentation. This talks about r_basicprofile (which I have used with v1), but this will be replaced with r_liteprofile. (I quote: "This API will only recognize a new “Lite Profile” permission, which supports a reduced set of member profile fields.")
So, r_liteprofile only has a couple of data fields (first name, last name, maiden name, profile picture). In the future, how am I to get the LinkedIn profile URL from this? And some other information that is not necessarily privacy sensitive?
If I try to get more data through r_liteprofile it doesn't show them, which would be expected behavior according to the r_liteprofile documentation. But how am I supposed to link to people's LinkedIn profile from my application? Doesn't LinkedIn want people to come back to their platform through other websites?
So, in conclusion:
After March 1st, will there still be a way to get the profile URL, and perhaps the headline and industry ID?
The obvious answer is "no you can't". I'm just hoping for a "yes you can".
In short: it's not possible to maintain the r_basicprofile fields without applying for a LinkedIn partnership, starting March 1st, 2019 (when the transition from the LinkedIn API v1 to v2 will be made).
From the migration docs:
"Looking to maintain access to the Basic Profile fields? Learn more about applying to a LinkedIn Partner Program."
https://learn.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/migration-faq?context=linkedin/consumer/context#what-are-the-main-differences-with-the-new-sign-in-with-linkedin
You can get more fields by specifying them in url:
https://api.linkedin.com/v2/me?projection=(id,firstName,lastName,profilePicture(displayImage~:playableStreams))
You can find more fields here https://learn.microsoft.com/en-us/linkedin/shared/references/v2/profile
I have written an app which uses the Instagram API to retrieve geotagged posts containing "#sunset" and related tags. On March 22 - 23 2016, the number of posts being collected dropped dramatically. Has anyone else observed this behavior, or do you have any suggestions for what I should look for? Is it possible there has been a change to Instagram's privacy policy that leads to fewer geotagged posts? I do not think it is due to a change in my code (I have not changed the code, and I am actually collecting the posts using two different methods, both of which display this pattern). Nor do I think it is due to my API key suddenly becoming invalid (the key seems to work).
UPDATE: I discovered other people have been having similar problems. See here:
Instagram API /tags/{tag-name}/media/recent changed behaviour
Instagram /v1/tags/{tag-name}/media/recent endpoint doesn't return min_tag_id in pagination block
UPDATE 2: it appears that both the Python + Ruby Instagram clients were deprecated on the same day, March 22, right before everyone started having this problem: https://github.com/facebookarchive/instagram-ruby-gem/commits/master, https://github.com/facebookarchive/python-instagram/commits/master
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.
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."