In short, we're working hard and making strides, but we have a lot of work to do. We love hearing feedback—keep giving it to us. It keeps us hungry to make things better.
Let me start by giving some kudos. I had a chance to use a GUI tool that lets a developer test FB API calls. I'm not sure if this is officially released yet but it was a fantastic tool and a step in the right direction! (fyi: I got the link from a presenter at a hackathon ... forget the details).
Like some of the other folks here, I have burned many many hours trying to get the FB API to behave nicely. I think the core issue is documentation coupled with the velocity with which things change. I understand that the mantra for the company is "Move fast, break stuff" but I don't think it is right for you to cause developers pain. While you folks might have a lot of dev resources, not everyone does. A lot of times, I can see the API changes being done for good ... i.e. rename paramters or move'em around. The problem is that if you don't flag the change and/or documented this, you've pretty much guaranteed developer pain.
I understand when you move fast, you don't have time to document. People naturally turn to blog posts. This adds to the pain because half the stuff works while the other doesn't. My experience using the API at a recent hackathon was piece together fragments from different blogs and hope for the best.
So if there is one line of feedback you take from this .... if you change your API, think about it from the external developers standpoint.
More documentation, up to date and better organized. I know you have made strides, but please don't slack.
You should be sending all developers weekly email blasts about upcoming changes, recent changes and known bugs.
I'm pretty sure my company would pay for some sort of VIP tech support, even if it was just someone we could ping who would simply respond with "oh, that feature was switched off last week".
The biggest problem I've found with the facebook api is their sloppiness in documentation - they often have multiple conflicting versions of api documentation online, with no structured versioning in place.
Several times I've seen functionality removed with nothing in the documentation indicating what had changed.
Documentation's a first, because there's no proper reference, and sometimes the thing you want is buried within another page. Or there are conflicts.
There's a certain lack of clarity and even when you can figure it out some of their decisions are strange. There's barely anything on performance and caching and overall they appear to have geared the API more towards the copy-paste plugin generators they have. I've never seen a 3rd party FB app (apart from the one linked on this page, Clarity I think, which I've only just heard of), and all the Android ones I came across were just site specific browsers wrapping the mobile page.
Compare it to Twitter, which has supported countless apps on practically any platform you can think of and appears to have actually considered a developer will use it. It's nicely laid out and appears to have proper thought put into it.
What really frustrates me is that there are some places in which options exist but simply aren't documented, and in other cases the various call options are listed but with no explanation, so you have no clue what each option actually does for you.
As the article mentions, a lot of the rankings seem to be influenced by the popularity of the service. Twitter and Facebook are going to have more complaints simply due to the fact that more people use them.
Twitter in particular has a very good API, I have never used Digg's, LinkedIn's, or Paypal's, but I doubt very much they are better documented and easier to use than Twitter's. (I have had some problems with Facebook's API, so perhaps it is deserving of its title.)
A better way to run this survey would be to only allow people who have actually used all the API's to vote. It would be difficult in my opinion to vote for an API as the worst with no basis of comparison.
Twitter's API has historically been very good. I think at least part of the issue with Twitter and developer satisfaction is that they have spent the last year doing just about everything they could to push developers off of making full featured Twitter apps using that API short of outright banning them from doing it.
Seems to me that the problem is more an issue of the process and politics of using the API (and widespread uncertainty as to how long the full API will be available given Twitter's signaled future plans) rather than technical/documentation problems with the API itself.
Exactly. LinkedIn doesn't really have much of an API in terms of the data you can get out of it. Facebook does, and I assume far more people use it because of that.
I'm the developer of Clarity, a Facebook Client for the Mac (http://www.clarity-app.com), and yes, the Facebook API is the worst I've ever had to use. Words fail me to explain how bad it is.
I wonder if there is a way to calculate the total cost of lost developer productivity due to Facebook bugs, changes, and bad documentation. I swear I spend way too much of my time dealing with it, and it sounds like everyone else does too.
Whilst I'm no fan of Facebook development, this survey doesn't seem to be that fair: one of the graphics it says it received 135 answers in total, 19 of which named Facebook's API. That's not many answers...
A few days ago, all our Graph API calls used to return errors. The error wasn't very verbose. It was a JSON object saying "Something was wrong". After pulling our hairs for some time, we realized that they removed the trailing slashes from the URLs. They are back with both forms(with and without trailing slash) now. But, it really wasted a lot of time because the error wasn't clear and the code needed changes.
Well, it would be nice if they kept it up more often. In my experience with Facebook, they have a severe problem with maintaining uptime. Facebook is synonymous with breakage for me.
Actually the Facebook API has been pretty impressive functionality-wise, over the years. At the initial launch in '07 I remember being blown away by how much you could do with it (FQL, FBML, etc). It was an order of magnitude more impressive than any web API at the time.
The big problem has always been stability as they have continuously developed it and deprecated and removed things at a breakneck pace. The documentation never kept up, and there was a lot of breakage along the way.
I still think this was the right decision for Facebook at the time. They had a lot of growth to do, and were plowing into new territory. It was more important to grow quickly and push greenfield developers in the right direction than to satisfy the long-time developers who were always smaller in number than the incoming batch.
Now, however, Facebook has hit an inflection point in growth, and I think they need to adjust their culture to serve developers and existing users better. I believe Facebook has found the core of what it is, and should now be building new functionality around that core and stabilizing it in order to maximize lock-in rather than breaking shit all the time and just asking people to migrate over the greener pastures. Of course that's just my frustrated developer perspective, it's probably not in Facebook's let alone Zuckerberg's DNA.
Having interfaced with the Facebook API when FQL and FBML were all the rage I'm left scratching my head at your comment.
> Actually the Facebook API has been pretty impressive functionality-wise, over the years.
What's your definition of functionality? To serve a purpose well, or the range of operations supported? In my experience neither of those things has been true of the Facebook API (granted I haven't touched it in the last ~2 years). "How much you can do" has actually been rather limited throughout the life of the API, and what it did do it didn't do very well. I have not-so-fond memories of dealing with orphaned state data that left the app I was working on irreversibly broken for the user.
Saying that the documentation never kept up is being too kind. The documentation was never in a complete form to begin with. I had to write a large amount of 'discovery' code just to tease out how much of the API really worked. The worst part was not being able to trust the code Facebook themselves shipped to interface with their own APIs. I had to patch the PHP library they provided just to get it to work at all.
> Now, however, Facebook has hit an inflection point in growth
Again, I'm not exactly sure what you mean, but if you're implying that they're now so big that they've got to start taking shit seriously I think you're again being to kind. Smaller startups (including many in the YC crowd) do a better job with less money and employees, and with much smaller user bases. Facebook dicks around with their APIs without concern for developers because they can. The growth rate and size of the user base is the problem, not the reason they need to clean up their act. Besides, Facebook has been huge for a long, long time now. Their culture clearly doesn't value outside input or concerns.
> I believe Facebook has found the core of what it is
You sound like a Facebook PR person, but I'll humor you. Let's say they have found their core. It certainly isn't a genuine respect for their users (consumers or developers). The easiest way to evaluate the company (for me) is to take away the popularity aspect and look at two things: the valuation and what they're actually making/producing/creating (insert favorite verb for what companies "do"). At 50+ billion dollars I see a company that makes a lot of noise about innovation, but does very little that is different than what it did when it launched in 2004 (at scale, granted). If that beginning kernel of "innovation" (which is arguably no different than MySpace with better design) justifies said valuation then so be it, but many other social networks with roughly equivalent features have come and gone. It doesn't seem clear what "core" they were searching for, or what (if anything) they found. Facebook has the network effect on its side and that's about it.
The hype is almost too much to watch sometimes. The media loves (needs) attention, and Facebook has a lot of it concentrated on its site. The media wants a piece, as I can vouch for having worked with a lot of ex-newspaper types, thus fueling the cycle. The reality is that the loyalty of people's attention is grossly over-estimated, and so is the value of that Facebook "does".
I'll paraphrase a thread I saw a while back here on HN. It depresses me that some of the best minds of my generation are working on how to make more people look at ads.
I'm not surprised. After serving as a maintainer of both the main perl client side api (http://search.cpan.org/dist/WWW-Facebook-API) and one production application I have to say the Facebook platform sucked[1] for its instability, lack of regression testing, lack of roadmap for new feature or fixes for major bugs and lack of a testing framework for client apis.
Now, this was 2 and 3 years ago they may have cleaned up the mess since but I don't think so after poking my head in a time of two over the last few months.
[1] It sucked to worked with but was an undeniable success for them and those that we able to dedicate the resources to keep up to the constant churn and downtime
Twitter and Google both have excellent APIs. Twitter's API is helped a great deal by every client built by Twitter is also built on the Twitter API.
Google's APIs, in my experience, have great documentation and an excellent learning curve. Want to do something simple? Well here's code that does that. Want to do a medium challenge? Use that code and this documentation to expand it - often projects can gain sophistication quickly with only tweaks here and there.
There's no doubt the Facebook API is terrible. You have to read several pages of text and answer a bunch of obtuse questions just to get your app registered. Then you have to deal with the oft mentioned documentation problems. The biggest problem I see is that its so hard to develop for, no one has built any decent third party libraries - as opposed to Twitter which has a ton of excellent libraries for interfacing with your favorite language.
I can't help but wonder if all of this is done on purpose. It seems to me that Facebook doesn't want anyone to be able to make as much money as them developing on their network, so they make it impossible. If there was a better API, there might be 10 Zyngas by now.
A few months after Facebook announced "Operation Developer Love (http://developers.facebook.com/blog/post/417/), I reported a bug I had found in the API. Their first response was to tell me I didn't know what I was talking about, and that is was functioning fine. After explaining myself better, they finally admitted it was a bug... and promptly informed me they would be marking it as WONTFIX because they didn't feel like addressing it at the time. Lost two days of work because of that bug, and they don't want to fix it... that's love for you. Here's the bug report for reference (I may have gotten just a bit testy, but still, it was pretty frustrating) http://bugs.developers.facebook.net/show_bug.cgi?id=16856
I had a brief experience with using Facebook's API last year. It was absolutely horrible. Documentation in the Wiki of features that no longer existed. Features that would just break with little or no explanation. Maybe it's improved since then but I would never try and use it again unless I absolutely had to.
After I saw the pie chart, I am wondering the proportion in the chart corresponds to usages of APIs.
So in fact, it is not Facebook API is the worst API but it is most widely used API. And this also shows how much power Facebook has now due to its tremendous data relevant to an internet users.
We weren't trying to bash on Facebook at all (and the survey had nothing to do with which services people liked/disliked).
Our main point was simply that the developer community really seems poorly served by the API players. And that rings true, scientific survey or not.
But clearly there were lots of things wrong with our initial survey (poor questions, limited sample size, etc.), but we'd very much like to run another survey and address theses issues as well as possible.
So please, chime in and let us know how we can take this up a few notches.
"Meanwhile, complaints about Google cited APIs that had been shut down or were missing."
So the quality of Google APIs is based, in part, on missing ones? I am not sure I understand. I can understand that API integration can cost time, and if Google decides to terminate an API project then that work is basically thrown away. But that doesn't reflect on the quality of Google's APIs, it reflects on the flakiness of Google as an API provider.
Also, "voting down" their API quality for not having APIs that the developers want hardly seems fair either.
P.S. Using API so many times in a comment is probably a great start for a tongue-twister.
I'm not sure that "they have shut down" should count against Google's APIs... because the ones that shut down are no longer Google APIs. Sure, count it against Google's services that not all of them have APIs.
I think the AWS team at Amazon should break open a bottle of champagne and congratulate themselves for not being anywhere on this list. AWS lives and dies by its API, and they've done a very good job of it.
Since recently when I'm asked to do Facebook apps I explain to my clients I need to charge them a Facebook tax. I can easily spend 50% of my time building a Facebook app on dealing with Facebook API issues.
[+] [-] MattKelly|14 years ago|reply
In short, we're working hard and making strides, but we have a lot of work to do. We love hearing feedback—keep giving it to us. It keeps us hungry to make things better.
[+] [-] iqster|14 years ago|reply
Let me start by giving some kudos. I had a chance to use a GUI tool that lets a developer test FB API calls. I'm not sure if this is officially released yet but it was a fantastic tool and a step in the right direction! (fyi: I got the link from a presenter at a hackathon ... forget the details).
Like some of the other folks here, I have burned many many hours trying to get the FB API to behave nicely. I think the core issue is documentation coupled with the velocity with which things change. I understand that the mantra for the company is "Move fast, break stuff" but I don't think it is right for you to cause developers pain. While you folks might have a lot of dev resources, not everyone does. A lot of times, I can see the API changes being done for good ... i.e. rename paramters or move'em around. The problem is that if you don't flag the change and/or documented this, you've pretty much guaranteed developer pain.
I understand when you move fast, you don't have time to document. People naturally turn to blog posts. This adds to the pain because half the stuff works while the other doesn't. My experience using the API at a recent hackathon was piece together fragments from different blogs and hope for the best.
So if there is one line of feedback you take from this .... if you change your API, think about it from the external developers standpoint.
[+] [-] rwhitman|14 years ago|reply
You should be sending all developers weekly email blasts about upcoming changes, recent changes and known bugs.
I'm pretty sure my company would pay for some sort of VIP tech support, even if it was just someone we could ping who would simply respond with "oh, that feature was switched off last week".
[+] [-] klochner|14 years ago|reply
Several times I've seen functionality removed with nothing in the documentation indicating what had changed.
[+] [-] jobu|14 years ago|reply
The number two issue is they change the API and don't announce the changes until people start posting questions asking why something is failing.
Number three is random failures with no error. (Did they change the API again or is it just a random recurring event?)
[+] [-] FuzzyDunlop|14 years ago|reply
There's a certain lack of clarity and even when you can figure it out some of their decisions are strange. There's barely anything on performance and caching and overall they appear to have geared the API more towards the copy-paste plugin generators they have. I've never seen a 3rd party FB app (apart from the one linked on this page, Clarity I think, which I've only just heard of), and all the Android ones I came across were just site specific browsers wrapping the mobile page.
Compare it to Twitter, which has supported countless apps on practically any platform you can think of and appears to have actually considered a developer will use it. It's nicely laid out and appears to have proper thought put into it.
[+] [-] michaelschade|14 years ago|reply
What really frustrates me is that there are some places in which options exist but simply aren't documented, and in other cases the various call options are listed but with no explanation, so you have no clue what each option actually does for you.
[+] [-] thestranger|14 years ago|reply
Twitter in particular has a very good API, I have never used Digg's, LinkedIn's, or Paypal's, but I doubt very much they are better documented and easier to use than Twitter's. (I have had some problems with Facebook's API, so perhaps it is deserving of its title.)
A better way to run this survey would be to only allow people who have actually used all the API's to vote. It would be difficult in my opinion to vote for an API as the worst with no basis of comparison.
[+] [-] georgemcbay|14 years ago|reply
Seems to me that the problem is more an issue of the process and politics of using the API (and widespread uncertainty as to how long the full API will be available given Twitter's signaled future plans) rather than technical/documentation problems with the API itself.
[+] [-] naz|14 years ago|reply
[+] [-] yesimahuman|14 years ago|reply
[+] [-] terhechte|14 years ago|reply
[+] [-] jgilliam|14 years ago|reply
[+] [-] Cushman|14 years ago|reply
Average dev hours to integrate with a typical API: 10?
Hours spent dealing with various Facebook API problems for every hour of real work: 1?
So figure... order of 100,000 dev hours? Adjust according to whatever you think those orders should be.
[+] [-] mootothemax|14 years ago|reply
Whilst I'm no fan of Facebook development, this survey doesn't seem to be that fair: one of the graphics it says it received 135 answers in total, 19 of which named Facebook's API. That's not many answers...
[+] [-] dheerosaur|14 years ago|reply
[+] [-] bryanh|14 years ago|reply
http://api-status.com/6404/50042/Facebook-Graph-API
[+] [-] dasil003|14 years ago|reply
The big problem has always been stability as they have continuously developed it and deprecated and removed things at a breakneck pace. The documentation never kept up, and there was a lot of breakage along the way.
I still think this was the right decision for Facebook at the time. They had a lot of growth to do, and were plowing into new territory. It was more important to grow quickly and push greenfield developers in the right direction than to satisfy the long-time developers who were always smaller in number than the incoming batch.
Now, however, Facebook has hit an inflection point in growth, and I think they need to adjust their culture to serve developers and existing users better. I believe Facebook has found the core of what it is, and should now be building new functionality around that core and stabilizing it in order to maximize lock-in rather than breaking shit all the time and just asking people to migrate over the greener pastures. Of course that's just my frustrated developer perspective, it's probably not in Facebook's let alone Zuckerberg's DNA.
[+] [-] ary|14 years ago|reply
> Actually the Facebook API has been pretty impressive functionality-wise, over the years.
What's your definition of functionality? To serve a purpose well, or the range of operations supported? In my experience neither of those things has been true of the Facebook API (granted I haven't touched it in the last ~2 years). "How much you can do" has actually been rather limited throughout the life of the API, and what it did do it didn't do very well. I have not-so-fond memories of dealing with orphaned state data that left the app I was working on irreversibly broken for the user.
Saying that the documentation never kept up is being too kind. The documentation was never in a complete form to begin with. I had to write a large amount of 'discovery' code just to tease out how much of the API really worked. The worst part was not being able to trust the code Facebook themselves shipped to interface with their own APIs. I had to patch the PHP library they provided just to get it to work at all.
> Now, however, Facebook has hit an inflection point in growth
Again, I'm not exactly sure what you mean, but if you're implying that they're now so big that they've got to start taking shit seriously I think you're again being to kind. Smaller startups (including many in the YC crowd) do a better job with less money and employees, and with much smaller user bases. Facebook dicks around with their APIs without concern for developers because they can. The growth rate and size of the user base is the problem, not the reason they need to clean up their act. Besides, Facebook has been huge for a long, long time now. Their culture clearly doesn't value outside input or concerns.
> I believe Facebook has found the core of what it is
You sound like a Facebook PR person, but I'll humor you. Let's say they have found their core. It certainly isn't a genuine respect for their users (consumers or developers). The easiest way to evaluate the company (for me) is to take away the popularity aspect and look at two things: the valuation and what they're actually making/producing/creating (insert favorite verb for what companies "do"). At 50+ billion dollars I see a company that makes a lot of noise about innovation, but does very little that is different than what it did when it launched in 2004 (at scale, granted). If that beginning kernel of "innovation" (which is arguably no different than MySpace with better design) justifies said valuation then so be it, but many other social networks with roughly equivalent features have come and gone. It doesn't seem clear what "core" they were searching for, or what (if anything) they found. Facebook has the network effect on its side and that's about it.
The hype is almost too much to watch sometimes. The media loves (needs) attention, and Facebook has a lot of it concentrated on its site. The media wants a piece, as I can vouch for having worked with a lot of ex-newspaper types, thus fueling the cycle. The reality is that the loyalty of people's attention is grossly over-estimated, and so is the value of that Facebook "does".
I'll paraphrase a thread I saw a while back here on HN. It depresses me that some of the best minds of my generation are working on how to make more people look at ads.
Edit: Minor point clarification.
[+] [-] clobber|14 years ago|reply
[+] [-] clscott|14 years ago|reply
Now, this was 2 and 3 years ago they may have cleaned up the mess since but I don't think so after poking my head in a time of two over the last few months.
[1] It sucked to worked with but was an undeniable success for them and those that we able to dedicate the resources to keep up to the constant churn and downtime
[+] [-] enjo|14 years ago|reply
[+] [-] padobson|14 years ago|reply
Google's APIs, in my experience, have great documentation and an excellent learning curve. Want to do something simple? Well here's code that does that. Want to do a medium challenge? Use that code and this documentation to expand it - often projects can gain sophistication quickly with only tweaks here and there.
There's no doubt the Facebook API is terrible. You have to read several pages of text and answer a bunch of obtuse questions just to get your app registered. Then you have to deal with the oft mentioned documentation problems. The biggest problem I see is that its so hard to develop for, no one has built any decent third party libraries - as opposed to Twitter which has a ton of excellent libraries for interfacing with your favorite language.
I can't help but wonder if all of this is done on purpose. It seems to me that Facebook doesn't want anyone to be able to make as much money as them developing on their network, so they make it impossible. If there was a better API, there might be 10 Zyngas by now.
[+] [-] jscheel|14 years ago|reply
[+] [-] cmurdock|14 years ago|reply
[+] [-] kalleboo|14 years ago|reply
[+] [-] eugenejen|14 years ago|reply
So in fact, it is not Facebook API is the worst API but it is most widely used API. And this also shows how much power Facebook has now due to its tremendous data relevant to an internet users.
[+] [-] AntiFreeze|14 years ago|reply
We weren't trying to bash on Facebook at all (and the survey had nothing to do with which services people liked/disliked).
Our main point was simply that the developer community really seems poorly served by the API players. And that rings true, scientific survey or not.
But clearly there were lots of things wrong with our initial survey (poor questions, limited sample size, etc.), but we'd very much like to run another survey and address theses issues as well as possible.
So please, chime in and let us know how we can take this up a few notches.
[+] [-] yariang|14 years ago|reply
So the quality of Google APIs is based, in part, on missing ones? I am not sure I understand. I can understand that API integration can cost time, and if Google decides to terminate an API project then that work is basically thrown away. But that doesn't reflect on the quality of Google's APIs, it reflects on the flakiness of Google as an API provider.
Also, "voting down" their API quality for not having APIs that the developers want hardly seems fair either.
P.S. Using API so many times in a comment is probably a great start for a tongue-twister.
[+] [-] corin_|14 years ago|reply
[+] [-] ianso|14 years ago|reply
[+] [-] pan69|14 years ago|reply