[Eduard]

My brief, frustrating experience maintaining a Facebook application consisted of the app breaking every two weeks as Facebook somewhat randomly changed things without warning.

When did you have this experience? How long ago is it? For now quite some time, Facebook has been open with upcoming "breaking changes", giving Facebook App developers three months in advance to adapt accordingly: https://developers.facebook.com/roadmap/change-policy/

[ripter]

How about two weeks ago? They fail to mention in their list of breaking changes that the id format would changed from profileId_postId_commentId to profileId:postId:commentIdThatMightContainUnderscores

Except that not all posts follow the new ID format. Not all new posts even follow it. It's now a mix of the two.

[rmc]

Here here. You can't trust the Facebook docs to be complete. I have numerous comments in our codebase of "Facebook API docs are wrong, it's actually X..."

[return0]

It's odd that they chose stackoverflow for their support system, because most of the answered questions there are way obsolete by now.

[wwweston]

They chose StackOverflow for their support system at one point.

At one point, they've also chosen a web forum, a wiki lots of devs bought into (but which they later entirely blew away and replaced with Bing searches of their site), and probably a half-dozen attempts at official on-site docs.

When I saw they'd offloaded to StackOverflow, I thought that was an idea that had some promise, but the big question in my mind was how long until it reached the critical mass where it would consist of more out-of-date answers than current ones. And what they'd do when it does.

The answer, of course, is likely move fast and break something, and heaven help the people who had the idea of building something on top of their quicksand.

[rmc]

a wiki lots of devs bought into (but which they later entirely blew away and replaced with Bing searches of their site)

They seemed to have fixed it now, but for a while the search box would return results from the wiki, which had been removed, leading you on an endless tempting "the answer you want is just around the corner" unhelpful drugery.

[ripter]

Somewhere on the site they actually tell you to use Stackoverflow because it's more up to date.

[chrisblizzard]

Do you have an example?

[chrisblizzard]

Do you have specific examples? I've killed a lot of docs-that-are-wrong over the last few months but I would love a list of anything I've missed.

[chrisblizzard]

Hi. I work on Facebook's documentation for developers. It's true that IDs are opaque and I don't think that we declare that anywhere in particular. (It's a known unknown?)

I've updated the Graph API getting started guide to mention the fact that IDs are opaque and also mentioned it in our comments guide since comments are one of the few places where we have IDs that are made up of other keys.

Thanks for the feedback - it's good to hear about things we can fix.

[0x0]

Is the comment ID format documented anywhere? I don't know the details, but to be honest this sounds like relying on undocumented behavior.

[ripter]

Just about everything except the basics is undocumented, or only documented via stackoverflow.

[jbert]

I'm not an fb developer and don't know the platform, but was that documented as the format? i.e. were you expected/allowed to destructure an id in that way or was it intended to be opaque?

[ripter]

You are allowed to deconstruct the id that way because it's the only way to get the information. It's not a property or value, it's part of the id. You then use these three parts to get the rest of the information.

It's not documented as a format (very little is) but it's been this way since at least 2011-ish.

If there is a better way to get this information it is also undocumented.

[jbert]

> You are allowed to deconstruct the id that way because it's the only way to get the information.

If the API has a usable purpose without providing that info, then I think I'd disagree with you - since you're reverse-engineering the implementation to get more data out.

Reverse engineering is OK, but implicitly carries the risk that stuff will change and break you without warning, in which case you can't really complain, in my opinion.

If the API's purpose can't be fulfilled without that info, then the API was probably broken as designed (you needed to parse the id to get the info, they just didn't document it).

[DominikR]

It's not that simple, the id returned for a post should allow to like/unlike the post according to documentation.

Liking works, but unliking does not in cases where the post_id returned has the profile_id prefixed. So you have to remove the profile_id from the post_id to unlike.

The reason why developers have to reverse engineer is that the Facebook platform doesn't and did never work the way it is documented.

Here's a bugreport for that problem which hasn't been solved since last February! (The top comment here with a workaround for that issue was created by myself: https://developers.facebook.com/bugs/539328566085833?browse=...)

[jbert]

OK, thanks for the detail.

I've suffered from having designed bad/limited APIs before and watching as people dig into bits I didn't want them to dig into, limiting what I can do in the future.

Not sure on the best way to avoid it, but I guess it's a 'nice problem to have' since at least people are using your API.

[ThomPete]

I built https://apps.facebook.com/pinviewer/ in 2012 and even up to there, FB changed things all the time without any warning.

[btipling]

2008-2009 I dealt with the Facebook API and they often broke things. The breaking changes notifications have improved things, but they still break things. Their insight analytics was broken for about a year. They just don't seem to care about their API.

[vinbreau]

Agreed. I've been working with their API for the last 2 years. When it does break it can take forever to get a response. I work for a Facebook preferred developer so we have an extra channel for getting bug feedback. If we weren't a preferred developer, we would have had API bugs go unaddressed for months. Sure there were warnings about some changes, but sometimes major changes occurred that we did not see coming and had to scramble to figure out workarounds.

[return0]

Preannounced or not, the fact is it's a dizzying rate for independent developers to catch up with.

[mratzloff]

2007-2008.