5 ms·

Good for prototyping, thanks. I'd be wary of using this in a live system though: relying on Google's public APIs/services is risky enough (Checkout is one examp

by surreal 13y ago

Good for prototyping, thanks. I'd be wary of using this in a live system though: relying on Google's public APIs/services is risky enough (Checkout is one example, Reader, etc) let alone an undocumented feature like this which could change/disappear suddenly. 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

dragonwriter 13y ago
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.
- surreal 13y ago
  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?
  - dragonwriter 13y ago
    > 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/#retrieving_a_list_of_spreadsheets https://developers.google.com/google-apps/spreadsheets/#retr...
    - surreal 13y ago
      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
      - dragonwriter 13y ago
        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.
afandian 13y ago
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.
- surreal 13y ago
  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
tjohns 13y ago
This feature is documented: https://developers.google.com/gdata/samples/spreadsheet_sample 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 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/ 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.)
dangerscarf 13y 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 https://github.com/jsoma/tabletop [2] https://github.com/jsoma/tabletop#okay-wait-weve-got-a-big-problem-but-a-solution-too https://github.com/jsoma/tabletop#okay-wait-weve-got-a-big-p... [3] http://productforums.google.com/forum/#!category-topic/docs/documents/0pneogfgzN0 http://productforums.google.com/forum/#!category-topic/docs/... [4] http://github.com/jsoma/flatware http://github.com/jsoma/flatware

by surreal 13y ago

dragonwriter 13y ago

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.

surreal 13y ago
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?
- dragonwriter 13y ago
  > 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/#retrieving_a_list_of_spreadsheets https://developers.google.com/google-apps/spreadsheets/#retr...
  - surreal 13y ago
    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
    - dragonwriter 13y ago
      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.

afandian 13y ago

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.

surreal 13y ago
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

tjohns 13y ago

This feature is documented: https://developers.google.com/gdata/samples/spreadsheet_sample 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 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/ 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.)

dangerscarf 13y 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 https://github.com/jsoma/tabletop [2] https://github.com/jsoma/tabletop#okay-wait-weve-got-a-big-problem-but-a-solution-too https://github.com/jsoma/tabletop#okay-wait-weve-got-a-big-p... [3] http://productforums.google.com/forum/#!category-topic/docs/documents/0pneogfgzN0 http://productforums.google.com/forum/#!category-topic/docs/... [4] http://github.com/jsoma/flatware http://github.com/jsoma/flatware