Anecdotes

[Aral Balkan]

To start, maybe we can collect some real-life anecdotes of your
experiences:

Have you been burned by the actions of an API provider in a way that
you believe should fall foul of basic developer's rights? Please tell
us. We can use this to try and draft a list of basic rights that we,
as developers, should have when using 3rd party APIs.

Thoughts?

[Thom]

Google Checkout has to be the worst for just randomly shutting you out
with no chance of appeal. Spend as long as you like working on the
integration and then if your project is a success, they consider too
much money going through to be a "risk", lock your account, charge
back all your transactions, even if you've already shipped things and
then ban you.

[@ikbenmartijn]

The API that has been the most frustrating to me in the last few weeks/
months is the Gowalla API.
If you take a look at it, or ever worked with it you'll get to know
what I'm saying here:
- No decent 'getting started guide' - I know we are devs after all but
hey, a little help...
- No decent documentation on the API calls, like we're supposed to
smell the data retrieved
- Very often changing calls, returns, without any communication of the
crew working on it
- No DEV-blog, no twitter warning devs about what changing
- Not a single way of contacting them properly next to the 'all-users'-
forum

...

[robert_t]

I make a significant part of my income from developing Facebook Apps.
Facebook's habit of changing their API, rewriting large chunks of the
API or simply just failing to provide a stable API/Platform for App
developers makes the environment a minefield for those such as myself.

I have developed Apps for clients on behalf of media agencies only to
find Facebook have changed something, making changes necessary to
simple restore developed functionality. Understandably, neither media
agency nor end client see why they should pay for the work necessary.
The result is that I'm now forced to add in a certain contingency to
every job just in case this should happen. Money aside, the extra
effort needed to "complete" a job or meet deadlines when one isn't
100% in control of the entire environment, is a potential major cause
of project stress, or even overrun - something not good for the
reputation.

An API provider should provide a a form of Service Level Agreement -
and not one that says they have none but one which commits them to
providing timely support and a stable environment. All changes to that
environment should be fully tested before being released and
developers should receive ample advanced warning of changes and be
able to benefit from a grace period after changes go live, during
which both "old" and "new" API features are supported. This eases
transitions and gives more time to react.

Facebook, for example, have no doubt benefited hugely from a large and
engaged developer community. To then not provide timely support to
those developers or to block API access to one of them without prior
communication is simply not acceptable.

More thoughts to come...

Robert

On May 13, 2:45 pm, Aral Balkan <aralbal...@gmail.com> wrote:

[Aral Balkan]

Facebook just disabled wall posting from my app – Feathers for
Facebook – without any notice or explanation as to why. The only thing
the app does is to allow people to post Facebook status updates with
fancy text styles, symbols, etc. (see http://feathersforfacebook.com).

To make matters worse, the app is currently _featured_ on the German
and Austrian app stores and this move means that it's is racking up 1-
star reviews.

The most frustrating part is that I had no notice and I still don't
know why it was disabled. I have no way of fixing the problem until I
know what it is. I've submitted an email to their developer support
email address but didn't even get an automated reply back to tell me
that it has been received and have no idea whom to talk to fix this.

There is something very wrong here. We, as developers, need a simple
set of basic rights. One of these should be that API providers should
not be able to randomly cripple our apps and hurt our livelihood (with
exceptions made for apps that spam/are abusive/break the law).

Aral
<snip>

[Paul]

Somebody has to play devils advocate, so..

It's difficult for me to get out of the mindset that their API is
theirs, to do with as they please/vote with your feet, etc. This
isn't to say that I think they're in the right, and that they
shouldn't extend support (and *courtesy*) to the people helping to
make their service more successful.

They get an extended offering from our efforts, but we get easy (most
of the time) access to a large market/cool toolset at low-cost/free
(and the biz opportunities from others wanting to use our skillset to
leverage it)

This view is no-doubt because I've yet to really rely too heavily on
any specific API, though I've had plenty of problems in the past,
mainly due to API downtime. If I'd had Aral's issues I'd likely be
posting burning turds through Facebook HQ's letterbox.

The proposed solution of a 'developer friendly' credential would go a
long way to help resolve these problems, as well as a place where
developers can easily check for the potential problems ahead/comment
on the dev-friendliness. At the very worst, it would get their
marketing team's attention.

[Pelle Wessman]

While I haven't really been burned by a provider I've been bugged by
some services confusing and limiting terms that makes it impossible to
really utilize the full extent of the API without being a lawyer.

I've also had some bad experiences with bug reports that hasn't really
been given any attention which lead me to have to do cumbersome
workarounds which somewhat clashed with the providers own terms of
service.

/ Pelle