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