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.
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.
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.
No, I'm specifically making the point that content negotiation and RESTful "APIs" aren't really APIs, they are just serving data up in the same way that you are serving HTML up. The whole API thing is just a social construction we have with these bizarre conventions around it.
It may be necessary to have big complicated APIs some of the time. Great. Mostly, it's not necessary: you have a URI structure, you have pointers between records (hyperlinks), you just need a machine readable representation of the data. HTTP and web architecture already does that. You don't need a special fancy API with things I need to learn and understand.
On reading your clarification: okay. You term what I call "data" as a "query result". Then it's a merely semantic distinction you are drawing. And, I'd suggest, probably an irrelevant one from the perspective of the data consumer. There's a URL for a resource. I want the stuff there. I don't care whether it's in a database or how it's stored. That's just plumbing.
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.