API Integration Pain? Ouch. (HN Survey Results)

http://blog.yourtrove.com/2011/08/11/api-integration-pain-survey-results/

by AntiFreeze • 15 years ago

27 12 15 years ago

blog.yourtrove.com

fehguy• 15 years ago

Sounds like the open-sourcing of http://swagger.wordnik.com is well timed and can help with this

Just like with any online survey, remember that the survey results are utterly meaningless. There is self selection bias for one. Even the initial post title for this survey was "How much does external API integration suck? (survey)". Thus you are already inviting only developers that really hate using external API's, for one reason or another (maybe they are gasp bad developers).

You also had timing bias: the post got only 20 upvotes, so it likely did not stay on the front page for that long. For the few hours it was there, most of the developers around the world were asleep or away from HN.

That is not to say, that your results are not interesting/thought provoking. Just pointing out that they are most likely not statistically significant in any way. As in, don't say "we should take pain X away because it got more votes than pain Y".

lisper4• 15 years ago

> OAuth (oh wow, do you hate OAuth)

If you hate OAuth, try DSSID: http://dswi.net/

icebraining3• 15 years ago

DSSID is just authentication. Most APIs need authorization, that is, a way for humans to let some client access their account on another service.

For authentication, I still prefer OpenID, especially since it's distributed (both BrowserID and DSSID tie you to a single provider).

lisper4• 15 years ago

It's true that DSSID is only authentication (for now). But I will be releasing the code once it has stabilized so anyone will be able to run a DSSID server.

jinushaun• 15 years ago

I don't understand why something so simple of an idea like OAuth should be so difficult and painful to implement. I hate it. We need a different solution, or a better reference implementation.

brlewis• 15 years ago

I spent an hour last night struggling with making OAuth client calls to Google (Picasaweb). I don't think a different solution is needed; I think Google just needs to implement the IETF spec correctly and provide better diagnostics. I don't know if Google started from a reference implementation.

pyre• 15 years ago

I had issues with the Posterous API (though I shelved that work a while back):

* The basic authorization didn't follow spec. Some frameworks handled this well (Perl's LWP::UserAgent), while others didn't (Python's urllib2 and httplib2). Apparently you're supposed to try the page w/o auth, get a 401 response back, then send the auth credentials, but Posterous' API was not doing this.

* Once you have an auth token, the API wouldn't allow me to authorize with it. I ended up sending basic auth for each API call for non-public calls.

* Some of the API calls would return 500 errors (namely the subscription related ones).

Granted this was prior to them releasing their snazzy new interactive API test page. I haven't gone back to touch that project since then, though I imagine that issues like this are common to a lot of APIs. How many of them are found and patched depends on how many developers are using the API and how responsive the API dev team is.

API Integration Pain? Ouch. (HN Survey Results)

Related Stories