It's a real shame that this rant has made it to the number one spot (as I of now). I don't mind rants, but there's nothing to really take away from this post. The author doesn't provide any motivation as to why any of these things are problematic, nor does he try to appreciate why some of these exist for some APIs. Rather than offensively ranting at people providing you with data, usually at no cost, why not try and provide examples of good web service design? This post could have been a whole lot more insightful.
Dear “API providers”, I don’t want a relationship.
31–40 of 52 posts
Re: Dear “API providers”, I don’t want a relationship.
#32What a ridiculously limited view of what apis do. What about being able to make a credit card payment, customize a google map, or do anything that involves interacting with a user account?
If the complaint is that there are needlessly complicated apis out there, it's a valid one. But the solution completely ignores any problem that does't fall into a very simple data provider model.
Re: Dear “API providers”, I don’t want a relationship.
#33Re: Dear “API providers”, I don’t want a relationship.
#34It's a real shame that this rant has made it to the number one spot (as I of now). I don't mind rants, but there's nothing to really take away from this post. The author doesn't provide any motivation as to why any of these things are problematic, nor does he try to appreciate why some of these exist for some APIs. Rather than offensively ranting at people providing you with data, usually at no cost, why not try and…
I didn't plan for it to get to the top of Hacker News. It's an off-the-cuff rant, basically a long tweet. I could write a long and detailed post about it, but this was written in the middle of hacking, while waiting for a long database query to run.
I apologise for the lack of insight.
Re: Dear “API providers”, I don’t want a relationship.
#35hmmm... this post is bewildering. Is there a particular API this is targeted at ? Some examples for each complaint would have been great to add more context. Lets look at your points...
I don’t want to build an application for your service.
I don’t want a relationship.
I don’t want to talk to any business development people.
I don’t want to read your developer blog.
I don’t want to participate in your “ecosystem”.
I don't recall any API agreement that dictates any of those. No one is forcing you to read a blog or change your relationship in facebook to 'in a relationship with twitter API'. I don't get this.
I don’t want to get an API key.
Fat chance. Some APIs need rate limiting / authentication. What do you have against obtaining an API key ? Its not that complicated. Most APIs provide BASIC auth or let you get OAuth tokens.
I don’t want to read your code samples.
ಠ_ಠ
What likely happened was that you were pissed with the API that someone provided. It had complicated requests where HTTP methods and simple structures alone were not enough to describe the request and to add to that you were given a freakin complicated way to retrieve auth tokens. You then decided to take it out on all API providers without providing enough context on your rant.
[EDIT] - formatting
Re: Dear “API providers”, I don’t want a relationship.
#36'I don’t particularly give a fuck'
Now, any reason why they should give fuck about you?
Re: Dear “API providers”, I don’t want a relationship.
#37I find it difficult to understand how you have come to this stance; if they are providing the API as a free service, why should they put themselves out in any way or more specifically risk the chance of abuse?
Also, on one hand you ask for unadulterated access to their data, but you explicitly don't want their free code samples? - "Give me free stuff, but not that, I don't want that!"
Re: Dear “API providers”, I don’t want a relationship.
#38It's a real shame that this rant has made it to the number one spot (as I of now). I don't mind rants, but there's nothing to really take away from this post. The author doesn't provide any motivation as to why any of these things are problematic, nor does he try to appreciate why some of these exist for some APIs. Rather than offensively ranting at people providing you with data, usually at no cost, why not try and…
It's an extreme position, but such views are still valuable.
I wouldn't advocate implementing an API to those bullet points, but it's certainly worth remembering when you are making an API that you aren't making it for you, the service provider.
As nothing but a reminder of that, the post is valid. It's certainly why I upvoted it... not because I think it's deeply insightful, but that it's good to have the reminder that on the other side of an API is a developer who I might be frustrating and causing problems for.
Re: Dear “API providers”, I don’t want a relationship.
#39hmmm... this post is bewildering. Is there a particular API this is targeted at ? Some examples for each complaint would have been great to add more context. Lets look at your points... I don’t want to build an application for your service. I don’t want a relationship. I don’t want to talk to any business development people. I don’t want to read your developer blog. I don’t want to participate in your “ecosystem”. I…
It's not taking anything out on anyone. It's a joke, a mild diversionary amusement, that for some reason that I can't understand people seem to think should be the #1 post on Hacker News.
Re: Dear “API providers”, I don’t want a relationship.
#40Earlier quoted context omitted.
There's a few things I'll push back on: I could harm your service by making too many API-key signed, OAuth-signed requests too. I could harm your service by hitting your website a lot too. We have ways of dealing with people who intentionally or unintentionally launch the equivalent of denial of service attacks: you block their IPs and move on. There's no need to have a special magical way of doing it with an API. Th…
Rants are always best with actual examples of what's being ranted. Just as http://tommorris.org/posts/2451
That post is totally wrong, though. There's no way in which URLs with opaque IDs in are better for humans than URLs with stubs. If the stub happens to jog a users memory about the content of the post, it might be useful, and even if it doesn't sum up the post very well, it's still no worse than an opaque ID.