The "Move Fast and Break Things" attitude is fine when you're releasing a complete product. Look at Twitter or GMail. Google and Twitter change their interfaces pretty much constantly, and outside of a few hours or days of grumbling, pretty much everyone goes back to using the services.
But if you're providing functionality that other people are coding against, it's a cardinal sin to break your API without warning everyone. When making API's, slower and more monolithic releases is often a better approach. It not only gives your teams time to develop and test the features, but it also gives downstream users of your API time to absorb the changes.
Apps aside, the proportion of basic wall pageloads that hang due to, I'm assuming, some javascript complexity approaches 100%.
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/
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.
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.
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.
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.
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.
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).
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=...)
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.
It was not completely obvious in 2007 that in-app virtual item transactions were to stay. Facebook itself was playing around with virtual gifts, but convincing users to pull out their credit card on a social network was novel.
It was pretty hard to predict specific monetization pattern - iLike looked into ticket-selling, Visual Bookshelf would do affiliate links to Amazon, Slide's apps would monetize through standard banner ads (and later video ads), Zynga was not even around at the time.
>> Otherwise, what's the point of building the platform?
Facebook displays its own ads on application canvas pages. Therefore higher engagement with apps => higher pageviews => higher earnings.
- Not building in a revenue model into their platform, like Apple did with iOS. This is so stupid.
- Not creating clear and consistent access rules around the social graph and notifications, with the ability to throttle down (but not altogether remove) access for offenders. They could even automate the throttling based on user feedback (in the form of clicks).
- Breaking things constantly. My brief, frustrating experience maintaining a Facebook application consisted of the app breaking every two weeks as Facebook somewhat randomly changed things without warning.
All of these were pretty foreseeable.