This feature is documented: https://developers.google.com/gdata/samples/spreadsheet_samp...

In fact, it's a core feature of GData: https://developers.google.com/gdata/docs/json#Request

That's not to say the API will never change, but if it does, it will be documented here: https://developers.google.com/google-apps/spreadsheets/

(Disclaimer: I used to be the Google Developer Relations engineer responsible for Spreadsheets, but that was ~4 years ago.)

I maintain a library[1] that's pretty popular with the journalism crowd for converting Google Spreadsheets to JSON, and you're exactly right about the risk[2]. Google's been sitting on a bug for over 6 months now because API usage of Google Spreadsheets just isn't important enough to merit a fix[3].

We've sent people off into the caching world[4] to fit it on our end, but your criticism is unfortunately spot-on.

[1] https://github.com/jsoma/tabletop

[2] https://github.com/jsoma/tabletop#okay-wait-weve-got-a-big-p...

[3] http://productforums.google.com/forum/#!category-topic/docs/...

[4] http://github.com/jsoma/flatware

Its using it behind an abstraction layer that decouples the substantive work of the rest of the app from the Google Spreadsheet API and storage backend, for the express purpose of limiting the impact of any later need to move to a different backend service. Given that Checkout and Reader -- the Google examples you cite as reasons to be wary of it for a live system -- were terminated with extensive notice, that doesn't seem like it would pose any problem with this approach.

Maybe the comparison wasn't the wisest, valid point.

But I stand by the fact that this seems like hacking an undocumented feature: "Copy the key=... part [...] and put it into this URL: [...]", which means it could easily be modified/removed with no notice period, and is therefore risky in a production system, no?

> But I stand by the fact that this seems like hacking an undocumented feature: "Copy the key=... part [...] and put it into this URL: [...]",

No, the key value for use in the API being the same that is displayed in the browser URL when working with the sheet is a documented feature:

https://developers.google.com/google-apps/spreadsheets/#retr...

I didn't dispute that. The key itself is fine. I'm just worried about using it for JSON retrieval! That part is undocumented as far as I can see, and therefore subject to change without notice

Huh. I thought that the Spreadsheet API was documented as an XML/JSON API, but it looks like only the XML is directly documented so ... poking around a bit more

The alt=json thing is a documented common feature of Google Data APIs, and the current Google Spreadsheets API is the target of the link in the list of Google Data APIs titled "Google Spreadsheets Data API". OTOH, the current v3 Spreadsheets API no longer has "Data" in the name, and there is a note on the Data APIs documentation that some Google Data APIs have been replaced with newer APIs that aren't Google Data APIs.

So, its at best an ambiguously-documented feature.

Yes and no. I built an app for a client on top of Google Fusion tables, which is nearly the same thing. It was acknowledged that the API could change (indeed it did mid-way through). Nothing is constant, but some things are more constant than others. You have to work out what's suitable on a case-by-case basis I think.

Agree. But I'd personally place 'using an undocumented feature that requires constructing a URL based on a parameter from a different URL' towards the 'unsuitable' end of the spectrum! Somewhere around the 'be careful' mark. Unless I'm missing some documentation