Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear “API providers”, I don’t want a relationship.

tommorris.org

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Dear “API providers”, I don’t want a relationship.

#41

Post by tommorris »

voyou wrote: post #40
opminion wrote: post #17

Earlier quoted context omitted.

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.

Try writing down "example.org/posts/1234" on a post-it note and then try writing down "example.org/posts/thing-with-a-long-name-with-lots-of-dashes". One is a lot more fun than the other.

Re: Dear “API providers”, I don’t want a relationship.

#44

Post by steverb »

tommorris wrote: post #12
duiker101 wrote: post #2

This is a quite arrogant post. I do not make APIs but I can understand some needs of the API providers. First of all you are being arrogant because you if you just want an URL and nothing more means that for you every API must be free and this is totally bullshit. Also giving you a URL and nothing more gives me no control on what you do. You could harm my service by doing too many request or god knows what and I coul…

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…

Wow. They charge 8 cents per text? Yeah, their API should come give you a massage at that price.

Re: Dear “API providers”, I don’t want a relationship.

#45

Post by jyap »

eps wrote: post #7
duiker101 wrote: post #2

This is a quite arrogant post. I do not make APIs but I can understand some needs of the API providers. First of all you are being arrogant because you if you just want an URL and nothing more means that for you every API must be free and this is totally bullshit. Also giving you a URL and nothing more gives me no control on what you do. You could harm my service by doing too many request or god knows what and I coul…

Counterpoint - http://api.dribbble.com

To be fair, that page does mention:

Currently, no API key is required, but this will likely change so we can better monitor usage and enforce the Terms of Use (below).

Re: Dear “API providers”, I don’t want a relationship.

#46

Post by tommorris »

steverb wrote: post #44
tommorris wrote: post #12

Earlier 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…

Wow. They charge 8 cents per text? Yeah, their API should come give you a massage at that price.

I don't particularly care about the price. I'm using it for things like sending myself a small number of simple notifications. I have a script that monitors a web app I maintain for work, and if it isn't responding, it sends me an SMS.

When the site is down, people can't do any work. If they can't do any work, they lose clients. If they lose clients, I don't have a job anymore.

If the point of using SMS were to actually build an SMS service, I'd spend more time worrying about it and choose one of the more fully-featured SMS providers. And if it were to be a commercial thing, sure, I'd talk to their business development people. But everything starts at the micro level: what could be a business idea in six months starts as a crappy little hack now.

Here's a point of comparison. Esendex are usually considered one of the better SMS providers. How much do they cost? Oh, let's have a look at their pricing page. Doesn't tell me. Lots of blather. And a nice phone number I can ring and talk to a salesman or I can sign up for a no-commitment free trial. I don't want to talk to a salesman, I want to send a flipping text to myself in this crappy little Python script I'm writing.

Re: Dear “API providers”, I don’t want a relationship.

#47

Post by jyap »

tommorris wrote: post #39
cinbun8 wrote: post #35

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

My main issue is that the article doesn't make logical sense and you signed it off:

Tom, a grumpy developer.

I think you are tapping into the negative sentiments of some other recent articles. Namely the "Do You Really Want to be Doing This When You're 50?" article.

Perhaps people are laughing at you, not with you?

Re: Dear “API providers”, I don’t want a relationship.

#48

Post by ucee054 »

tommorris wrote: post #12
duiker101 wrote: post #2

This is a quite arrogant post. I do not make APIs but I can understand some needs of the API providers. First of all you are being arrogant because you if you just want an URL and nothing more means that for you every API must be free and this is totally bullshit. Also giving you a URL and nothing more gives me no control on what you do. You could harm my service by doing too many request or god knows what and I coul…

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…

A URL is not a way of saying where data is.

It is a way of naming a data query.

HTTP GET is not a way of retrieving data.

It is a a way of launching a query.

In the general case, the data is going to be in an enterprise datawarehouse divided over 200 tables each of which could be terabytes in size.

The schema design will mean that each table individually is meaningless, and you will probably not understand it all without a lot of documentation.

If you were allowed to pull a table using a GET it would almost certainly be very expensive for the service provider, and might kill your download connection.

APIs were invented to deal with these cases.

Re: Dear “API providers”, I don’t want a relationship.

#49

Post by tommorris »

ucee054 wrote: post #48
tommorris wrote: post #12

Earlier 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…

A URL is not a way of saying where data is . It is a way of naming a data query . HTTP GET is not a way of retrieving data . It is a a way of launching a query . In the general case , the data is going to be in an enterprise datawarehouse divided over 200 tables each of which could be terabytes in size. The schema design will mean that each table individually is meaningless, and you will probably not understand it al…

The data is there in an HTML page. I'm looking at it. I just want to stick ".xml" or ".json" on the end and see the exact same thing in a machine readable form.

Whatever complex enterprise data warehousing you are doing to get it in my browser as an HTML page is very impressive, I'm sure.

It can be as complicated as you want it to be if you want to offer something more complicated than that. But for the basic use case, I fail to see why exactly it has to be more complicated than using HTTP to GET things that are on the damn web. And all the talk of APIs makes people think it needs to be complicated when it doesn't.

Re: Dear “API providers”, I don’t want a relationship.

#50

Post by ucee054 »

tommorris wrote: post #49
ucee054 wrote: post #48

Earlier quoted context omitted.

A URL is not a way of saying where data is . It is a way of naming a data query . HTTP GET is not a way of retrieving data . It is a a way of launching a query . In the general case , the data is going to be in an enterprise datawarehouse divided over 200 tables each of which could be terabytes in size. The schema design will mean that each table individually is meaningless, and you will probably not understand it al…

The data is there in an HTML page. I'm looking at it. I just want to stick ".xml" or ".json" on the end and see the exact same thing in a machine readable form. Whatever complex enterprise data warehousing you are doing to get it in my browser as an HTML page is very impressive, I'm sure. It can be as complicated as you want it to be if you want to offer something more complicated than that. But for the basic use cas…

On your web page you say "I just want the data on your website in a machine readable format. XML, JSON, RDF, CSV, YAML, I don’t particularly give a fuck. ... I don’t want a relationship with you, I just want to have a fiddle with your data."

But in your comment you say "The data is there in an HTML page. ... I just want to stick .xml or .json on the end and see the exact same thing in a machine readable form."

In the first case, you are asking for the absence of an API. In the second case, you are asking for an API that apes the user interface.

I just wanted to point out that that's an important difference.

EDIT: It is not correct to say the data is in the web page already, it is more accurate to say the needed query result is in the web page.

Post reply on HN