API Integration Pain? Ouch. (HN Survey Results)(blog.yourtrove.com)
blog.yourtrove.com
API Integration Pain? Ouch. (HN Survey Results)
http://blog.yourtrove.com/2011/08/11/api-integration-pain-survey-results/
6 comments
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".
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".
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.
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.
Sounds like the open-sourcing of http://swagger.wordnik.com is well timed and can help with this
> OAuth (oh wow, do you hate OAuth)
If you hate OAuth, try DSSID: http://dswi.net/
If you hate OAuth, try DSSID: http://dswi.net/
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).
For authentication, I still prefer OpenID, especially since it's distributed (both BrowserID and DSSID tie you to a single provider).
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.
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.
If you let the users choose their own server (by putting its URL), then you've just reinvented OpenID.
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.
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?
Wouldn't it be better to use a personal cert?
> But the user still needs to copy the data between servers, no?
Yes, if you want to use multiple servers you need to get your data on multiple servers. But that's just a consequence of the laws of physics. It has nothing to do with DSSID.
> And what happens if the personal clears all the cookies in FF and deletes the Local Storage?
If they haven't made a backup copy of their key then they are screwed. You can't stop people from deliberately shooting themselves in the foot. If they have made a backup copy of their key then they can just re-import it.
> Wouldn't it be better to use a personal cert?
All else being equal yes. But the UI/UX for certs is so hopelessly bad that not even technically savvy people use them. DSSID's goal is to be secure and simple. That's a currently unoccupied point in the design space. (It's not easy to do.)
Yes, if you want to use multiple servers you need to get your data on multiple servers. But that's just a consequence of the laws of physics. It has nothing to do with DSSID.
> And what happens if the personal clears all the cookies in FF and deletes the Local Storage?
If they haven't made a backup copy of their key then they are screwed. You can't stop people from deliberately shooting themselves in the foot. If they have made a backup copy of their key then they can just re-import it.
> Wouldn't it be better to use a personal cert?
All else being equal yes. But the UI/UX for certs is so hopelessly bad that not even technically savvy people use them. DSSID's goal is to be secure and simple. That's a currently unoccupied point in the design space. (It's not easy to do.)
* 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.