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.
Related
Say you want to have a kickstarter-like site using Flattr, where you create a Thing for each individual user. How would you be able to tell (with the API) how much each user Flattr'd? It wouldn't update right away (it would have to update at the first of each month), but would it be possible at all? If there's no way to do this, could you tell how much a particular Flattr'd to you in total?
In the details of each months revenue reports there's a link to download that revenue report as a CSV-file which you could then import into your system to find out how much each thing has received. The information is not yet exposed through the API (see this question) so you would have to download the files manually - luckily there's only twelve months a year so it's not too much work to do :)
The CSV-file contains these columns:
period - Date in the format of YYYY-MM
id - The internal numeric id of the flattr thing
flattr url - The URL to the thing on Flattr.com
url - The original URL that the thing is pointing to
title
clicks - The amount of clicks for the thing during the period
revenue - The revenue for the thing during the period
clicks total
So - as you see you can't see how much each individual click has been worth if a thing has received more than one click and you can't either see which users it is that has clicked the thing (you can however see some of the users by asking the regular API for more information, but since some users are anonymous you can't figure out who they are without asking them for permission to do so).
If you really need to know if a user has flattred something, then you can force them to flattr the thing through your system by having them authenticate with your system using the Flattr API - that way you will at least know if a flattr has been made by the user or not, but you will still have trouble trying to figure out how much their flattrs are worth - but that's kind of the point with Flattr - that people should spend whatever they personally feel comfortable with rather than spending what others think they should be spending.
Ok I have looked into this, and I'm not sure if anyone else has experience with it. I'm having termendous difficulties with Yelp and Google's API.
To help explain what I am trying to do here is the concept of the website. We would have to pull restaurants based on user distance, and then randomize them based on quality of restaurant based on feedback from review websites (Yelp, Google, urbanspoon, zagat, opentable, kudzu, yahoo - doesn't have to be from all), and feedback from our users (on results page for the random restaurant users can select good recommendation/bad recommendation). There’s a lot we could calculate for our formula. Things that will dictate your results will be based on if you’re at home or work. If you’re at home you will have more time to drive out to the city to grab some dinner or lunch. If you’re at work we would have to recommend restaurants nearby as lunch is typically 30 minutes to a hour. A 30 minute lunch would require take out most likely or quick service. A hour lunch break you could dine in at a local fine dining restaurant. So in a nutshell, user comes to website. Select if they're at home or work, click submit and we will have a random restaurant selected for them to go. If they don't like it they can click retry and a new restaurant can show.
The issue I am having is using the API to gather all the restaurants in the US. I know it can be done because there are similiar websites/apps that pull restaurants that are closest to you such as Ness, Alfred, and I believe there's two more but I can't remember the names.
Anyone know if this can be accomplish? As I desperately need some help. Thanks in advance!
Yelp is the API that can provide you list of restaurant as per your search, your search can be area specific, lattitude/longitude specific etc. there are number of API through which you can see the reviews of different restaurant and put some logic based on that.
I think the logic of home/work order is something that you have to integrate in your application, yelp API can provide you with the results as per your search.
Go through their documentation for further information.
http://www.yelp.com/developers/documentation/v2/search_api
I couldn't help noticing yesterday that on the Graph API, a normal request for a page you're owner of, (like let's say http://graph.facebook.com/AnyPageYouAreAdmin with you being authenticated (you can try the call here)) would return a new field. This field is called 'new_like_count' and I kind of imagine what is it for. I can guess it will measure the growth of your fans.
What I would like to know is some extra information about it, like for how many days Facebook counts a 'like' as 'new' and these sort of specs that will make the field useful for developers.
Thanks in advance!
Julio,
The new_like_count is the number of new likes since the page has been viewed - this is only viewable by the page admin.
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."
Let's say user A follows user B, and B follows A. I want to know the exact date A started following B and viceversa.
Is this information stored on twitter? Can I retrieve it using the API?
To clear out: The point of this question is finding a way to know who followed who first.
(I'm assuming both A and B deleted the notification e-mails)
No Ignacio, you can't. You just can know who follows who but not the date the follow started.
Looking at the API, there's is no way, there are two calls to get the followers:
User Methods/statuses/followers
and
Social Graph Methods/followers/ids
Neither of them returns dates or even a serial that would let you see who started following first. Really, there's no indication that twitter is internally storing this information, neither in the API nor Twitter's web interface.
This is a very old question, but perhaps some might be interested to know that while you cannot get the date at which someone started following, you can at least infer an "earliest possible following date" from the fact that the list of followers is ordered according to date, and the fact that follower objects come with a created_at timestamp.
Here's a Python function for calculating an "earliest possible following date": https://github.com/BernhardClemm/twitter-follow-dates
Of course Twitter stores it, because Twitter sorts followers and following lists by the date ;)
It is possible to do this, but impractical. When you call the followers API you can page the results. Each returned object contains next_cursor and prev_cursor items. These refer to the first and last records in the next and previous pages. These values are time based and can be used to calculate the time that the respective users followed you.
It follows that, if you set the page size to 1, you can walk through the list of follower IDs one at a time and the next_cursor value will allow you to derive the follow time for the next record.
This is reasonably simple to implement, however, in practice, you'll very quickly hit Twitter's API rate limit.