4 ms·

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.

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.

ucee054 14y ago
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.
- tommorris 14y ago
  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.

ucee054 14y ago

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.

tommorris 14y ago
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.