4 ms·

API Integration Pain? Ouch. (HN Survey Results)

27 points by AntiFreeze 15y ago

fehguy 15y ago
Sounds like the open-sourcing of http://swagger.wordnik.com http://swagger.wordnik.com is well timed and can help with this
- EllieAsksWhy 15y ago
  What does that site have to do with developer dissatisfaction with API's?
fehguy 15y ago
Sounds like the open-sourcing of http://swagger.wordnik.com http://swagger.wordnik.com is well timed and can help with this
IgorPartola 15y ago
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".
- EllieAsksWhy 15y ago
  For reference, here's the original post http://news.ycombinator.com/item?id=2627571 http://news.ycombinator.com/item?id=2627571 with 20 up votes and some other corroboration of what @IgorPartola mentioned.
lisper 15y ago
> OAuth (oh wow, do you hate OAuth) If you hate OAuth, try DSSID: http://dswi.net/ http://dswi.net/
- icebraining 15y 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).
  - lisper 15y 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.
    - icebraining 15y ago
      Yes, but the site has to link to the server. So either the user has accounts on every DSSID server - losing the SSO advantages - or everyone uses the same server. If you let the users choose their own server (by putting its URL), then you've just reinvented OpenID.
      - lisper 15y ago
        The difference is that your identity is not bound to the server, it's bound to your DSSID key, which resides (encrypted) in your browser's localStorage. So you can move your (public) key to any server and retain your identity.
        icebraining 15y ago
        But the user still needs to copy the data between servers, no?And what happens if the personal clears all the cookies in FF and deletes the Local Storage? Wouldn't it be better to use a personal cert?
jinushaun 15y 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 15y 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 15y 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.

27 points by AntiFreeze 15y ago

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

EllieAsksWhy 15y ago
What does that site have to do with developer dissatisfaction with API's?

fehguy 15y ago

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

IgorPartola 15y ago

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

EllieAsksWhy 15y ago
For reference, here's the original post http://news.ycombinator.com/item?id=2627571 http://news.ycombinator.com/item?id=2627571 with 20 up votes and some other corroboration of what @IgorPartola mentioned.

lisper 15y ago

> OAuth (oh wow, do you hate OAuth) If you hate OAuth, try DSSID: http://dswi.net/ http://dswi.net/

icebraining 15y 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).
- lisper 15y 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.
  - icebraining 15y ago
    Yes, but the site has to link to the server. So either the user has accounts on every DSSID server - losing the SSO advantages - or everyone uses the same server. If you let the users choose their own server (by putting its URL), then you've just reinvented OpenID.
    - lisper 15y ago
      The difference is that your identity is not bound to the server, it's bound to your DSSID key, which resides (encrypted) in your browser's localStorage. So you can move your (public) key to any server and retain your identity.
      - icebraining 15y ago
        But the user still needs to copy the data between servers, no?And what happens if the personal clears all the cookies in FF and deletes the Local Storage? Wouldn't it be better to use a personal cert?

jinushaun 15y 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 15y 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 15y 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.