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.

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".

Several times I've seen functionality removed with nothing in the documentation indicating what had changed.

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?)

Let me publicly say something I've said privately: I will pay up to $1000/year for a subscription to a service that 1) documents the facebook APIs, 2) monitors examples and common usages and lets me know when they stop working, and 3) provides a weather report for the Facebook API servers letting me know when they're slow or sick.

Heck, I might pay more. We waste far too much developer time dealing with the problems Jobu so rightly points out.

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.

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.

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.

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.

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...

http://api-status.com/6404/50042/Facebook-Graph-API

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.

> 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.

Think back to 2006. Name one site that had sanitized SQL access to their data, rich tags, sandboxed css and javascript for constructing arbitrary HTML apps within their site. This was revolutionary stuff, regardless of the sloppiness.

> 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.

What I mean is that they were growing like a weed because they kept pushing the ball forward rather than to stop and polish what they had. If they had "done right" by all the developers they may well have stagnated in growth as other companies pushed the UX of social networking forward, or they may have supported old APIs that were incompatible with the changes they made that tightened up the spam problems or increased user engagement. Citing a smaller startup is exactly in support of my point.

As to inflection point, what I mean is that the hockey stick growth is over and they are inevitably going to have to plateau, and so now is the time to get more serious about retention, and that means stability.

> 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).

You're entitled to your opinion of course, but they invented the newsfeed! ie. the backbone of every social site for the last 5 years. Also, as I mentioned above, the Facebook platform was incredibly innovative. Their SOA and pipelining of requests is also the first of it's kind. What they do at scale with a dense social graph seems much much more challenging that what Google did coming up. Their entire culture itself is innovative, maintaining daily deploys at scale, with a fleet of engineers who are individually responsible for both front and back-end development of their features. Also remember the scale and velocity issues are what sunk Friendster and MySpace respectively.

You can piss on all that and say it's just glorified email, but in my mind that's just hater-ism fueled by who knows what personal chip on your shoulder. If not, then I'm curious to hear who you think is innovative.

> It depresses me that some of the best minds of my generation are working on how to make more people look at ads.

I don't like Facebook or social games either.

Salesforce.com was founded in 1999. They've had some of what you quoted for some time. Also note that the Facebook API features you mentioned (FQL & FBML) are now deprecated. I imagine in large part because they were difficult to pull off reliably.

> ... they kept pushing the ball forward rather than to stop and polish what they had...

An API is a contract with your third-party developers. They could have slapped the "beta" label on it (à la Google) and then pointed at that, but they didn't. They put this stuff out there so as to establish a platform for others to build on. It's hard to argue that the foundation for said platform was solid. In school my teachers never gave me better grades when I insisted that my last paper sucked because I was working so hard on making the next one awesome.

> ... but they invented the newsfeed!

So gut check yourself. Is that worth 50+ billion dollars? Novel information displays warm my heart, but this isn't giving anyone a new way to peer into the human body or discover never before seen patterns.

> Their SOA and pipelining of requests is also the first of it's kind.

Have you seen a single thing about Google's infrastructure... ever?

> What they do at scale with a dense social graph seems much much more challenging that what Google did coming up.

Now I think you're trolling. You think it's more challenging to throw together a stream of updates based on a graph that's handed to you versus having to correlate millions (shortly after, billions) of semi-structured documents to answer loosely worded questions?

Mark? Is that you?

Maybe so, but does it mean it wasn't innovative? As for Salesforce, you may be right, I'm not familiar with their product history.

> So gut check yourself. Is that worth 50+ billion dollars?

Whoah, where did 50 billion enter the equation? I'm just saying Facebook has been very innovative. If you want my opinion on Goldman Sachs you'll have to wait for another story.

> Now I think you're trolling. You think it's more challenging to throw together a stream of updates based on a graph that's handed to you versus having to correlate millions (shortly after, billions) of semi-structured documents to answer loosely worded questions?

Look, I don't want to get into a pissing contest about other people's tech. Web-scale anything is hard. The reason I think social is harder is because of the realtime graph traversal. When Google started it was months and months between indexings on most pages. Fulltext indices were something that already had a lot of practical knowledge behind them. I'm not trying to say that what Google did was easy, and neither should you trivialize what Facebook did.

Really?

Didn't RSS get popularized in like... 2003?

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

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.

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.

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.

Honestly the only thing I've noticed that has made me mad was that they started requiring a permission called "group_access" to view what are normally publicly available groups.

To be honest, I actually like the graph API. I think it's really intuitive, and it make perfect sense to me.

If I had to say "worst", I'd probably pick grooveshark, or twitter.