3 ms·
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
by 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 agoNo, 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.