|
|
|
|
|
by iqster
5423 days ago
|
|
Thanks for taking notice Matt. 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. |
|