However I do enjoy the API. It's wonderful how easy it is to prototype an idea and get it off the ground with minimal effort.
My team is currently using it as a makeshift JSON level editor for a mobile game where each tab represents a collection of objects and the schema is defined dynamically by whatever is in the frozen header row. (think Backbone collections and models).
If someone is interested in a project, email is in my profile. I've gotten very lucky meeting smart people through HN before, so why not try again!
Edit: it has been pointed out that the criticism of their documented/public APIs may be unjustified. The issue here is that this particular feature is undocumented
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.)
We've sent people off into the caching world to fit it on our end, but your criticism is unfortunately spot-on.
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?
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:
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.
Its pretty easy to setup your own:
Sometimes google will make already logged in users reauthenticate. It will redirect to the authentication page and you'll get a bunch of HTML rather than json returned, and the user won't know why it's not working.
It's the same reauth you sometimes get when visiting a public blogger site. It is an edge case, but quite unpredictable and hard to track down from client reports.
I'm using it a lot lately as I have to create static sites with a bunch of different translations. I have the translators edit a set template, which is aggregated into a single sheet. Then, a (racket.. could be python or anything) script reads from the published csv and outputs all the translated pages. Super useful.
This postContactToGoogle function gets around the cross-domain issue: http://www.tinkerpopbook.com/js/script.js -- props to the base22 team for the tip (https://wiki.base22.com/pages/viewpage.action?pageId=7294200...).
Unfortunately the option for creating the old-style Google Form is not directly available since Google switched everything over to Google Drive (if anyone knows how to access it please let me know) so I cloned/copied an existing old-style form for future use.
But it is an easy interface for unskilled users to add data to say a graph on a website, have done that for clients and they have been very happy.
As a historical note, these identifiers used to be part of the URL, long ago. The newer version of the Spreadsheets frontend doesn't use them, but they're still used by the Spreadsheets API.
I got used to daily time out messages, but waiting 1 min for a (cached!) 10 kb JSON list is far too much. However, organizing and correcting data using an online spreadsheet saves a lot of time and is kinda fun.
We're relying on schema.org normalization: no more item.gsx$stuff everywhere + switching or mixing data providers is effortless.
It does seem pretty broken with the latest Chrome (seems like menu items now require a double click?), so I'll take a look and try to get it fixed soonish.
You can see it working at http://stuartk.com/bundle/ (data from https://docs.google.com/spreadsheet/ccc?key=0Ar35F5WUAjXedDY... )
This is combined with with Google forms to allow people to submit new data, and the publish to RSS feature, although the content of the RSS feed isn't very pretty.
I wrote up some notes from the experience, as Google Spreadsheets is full of quirks and some of the APIs and other means of access are very easy to break - it is very easy to create a spreadsheet that will return broken JSON, for example, in some modes, and then cannot be fixed (ever) to return unbroken JSON.
The app is at http://find.megaphonemagazine.com (best viewed on a smartphone) and the code is open source at https://github.com/denimandsteel/megaphone. Case study is at http://denimandsteel.com/work/megaphone-finder/
I am the person who wrote the coderwall tip and I am sorry to hear that you feel like this. Especially because I did read your post a while ago, forgot about it and lost the link. I then just searched the GData docs and it's a documented feature. https://developers.google.com/gdata/samples/spreadsheet_samp... so I just spread something lesser known and didn't mean to "steal" anything.
has been doing this to present their data.
It's greatly sped up our process for visualization.