<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: API v2 feedback: files' &amp;quot;.tag&amp;quot; attribute extremely unfriendly for HTTP/JSON in Dropbox API Support &amp; Feedback</title>
    <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158905#M5395</link>
    <description>&lt;P&gt;Thanks for the feedback! I think you're specifically talking about JavaScript, right?&lt;/P&gt;
&lt;P&gt;The dot wasn't meant to indicate that the field is private–clients definitely need to read it. It was meant to&amp;nbsp;be in a&amp;nbsp;namespace that would never cause collisions. A dot seemed like a good way to do that, since it's uncommonly used in a JSON dictionary key.&lt;/P&gt;
&lt;P&gt;It's unfortunately too late to change this for API v2, which just recently came out of beta. But we could consider changing it in a future version of the API. I'd love to hear&amp;nbsp;specific examples&amp;nbsp;ofwhere this causes trouble, e.g. in lodash.&lt;/P&gt;
&lt;P&gt;This seems to work fine:&lt;/P&gt;
&lt;PRE&gt;var files = _.filter(entries, '.tag', 'file');&lt;/PRE&gt;</description>
    <pubDate>Thu, 19 Nov 2015 23:19:52 GMT</pubDate>
    <dc:creator>Steve M.</dc:creator>
    <dc:date>2015-11-19T23:19:52Z</dc:date>
    <item>
      <title>API v2 feedback: files' ".tag" attribute extremely unfriendly for HTTP/JSON</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158904#M5394</link>
      <description>&lt;P&gt;I'm using v2 of the HTTP API and wanted to pass along some feedback.&lt;/P&gt;
&lt;P&gt;When I hit a files list from an endpoint like files/list_folder, I get a JSON response like this:&lt;/P&gt;
&lt;P&gt;{ entries:&lt;BR /&gt; [&lt;BR /&gt;&amp;nbsp; { '.tag': 'file',&lt;BR /&gt;&amp;nbsp; &amp;nbsp; name: 'foo.pdf',&lt;BR /&gt;&lt;SPAN&gt;&amp;nbsp; &amp;nbsp; path_lower: '/foo.pdf',&lt;BR /&gt;&amp;nbsp; &amp;nbsp; &lt;/SPAN&gt;&lt;SPAN&gt;id: 'id:abcdefg',&lt;BR /&gt;&amp;nbsp; &amp;nbsp; &lt;/SPAN&gt;&lt;SPAN&gt;client_modified: '2015-11-16T00:50:26Z',&lt;BR /&gt;&amp;nbsp; &amp;nbsp; &lt;/SPAN&gt;&lt;SPAN&gt;server_modified: '2015-11-16T00:50:26Z',&lt;BR /&gt;&amp;nbsp; &amp;nbsp; &lt;/SPAN&gt;&lt;SPAN&gt;rev: 'd3adb33f',&lt;BR /&gt;&amp;nbsp; &amp;nbsp; &lt;/SPAN&gt;&lt;SPAN&gt;size: 8675309&amp;nbsp;},&lt;BR /&gt;&amp;nbsp; ...&lt;BR /&gt;],&lt;BR /&gt;cusor: ...&lt;BR /&gt;}&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;Passing back attributes like ".tag" makes it extremely difficult to work with in JSON. &amp;nbsp;eg the only way to access it is with the string accessor: result['.tag']. &amp;nbsp;Many popular&amp;nbsp;data manipulation libraries like lodash break when trying to define simple filters or accessors for this property.&lt;/P&gt;
&lt;P&gt;Since the HTTP API speaks&amp;nbsp;JSON, it would be&amp;nbsp;far more developer-friendly to use proper json attribute names. &amp;nbsp;If the attribute is meant to "private", the underscore convention would be more appropriate, eg 'result._tag'&lt;/P&gt;</description>
      <pubDate>Wed, 29 May 2019 09:38:20 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158904#M5394</guid>
      <dc:creator>Dan L.10</dc:creator>
      <dc:date>2019-05-29T09:38:20Z</dc:date>
    </item>
    <item>
      <title>Re: API v2 feedback: files' ".tag" attribute extremely unfriendly for HTTP/JSON</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158905#M5395</link>
      <description>&lt;P&gt;Thanks for the feedback! I think you're specifically talking about JavaScript, right?&lt;/P&gt;
&lt;P&gt;The dot wasn't meant to indicate that the field is private–clients definitely need to read it. It was meant to&amp;nbsp;be in a&amp;nbsp;namespace that would never cause collisions. A dot seemed like a good way to do that, since it's uncommonly used in a JSON dictionary key.&lt;/P&gt;
&lt;P&gt;It's unfortunately too late to change this for API v2, which just recently came out of beta. But we could consider changing it in a future version of the API. I'd love to hear&amp;nbsp;specific examples&amp;nbsp;ofwhere this causes trouble, e.g. in lodash.&lt;/P&gt;
&lt;P&gt;This seems to work fine:&lt;/P&gt;
&lt;PRE&gt;var files = _.filter(entries, '.tag', 'file');&lt;/PRE&gt;</description>
      <pubDate>Thu, 19 Nov 2015 23:19:52 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158905#M5395</guid>
      <dc:creator>Steve M.</dc:creator>
      <dc:date>2015-11-19T23:19:52Z</dc:date>
    </item>
    <item>
      <title>Re: API v2 feedback: files' ".tag" attribute extremely unfriendly for HTTP/JSON</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158906#M5396</link>
      <description>&lt;P&gt;The files search API returns lists like:&lt;/P&gt;
&lt;P&gt;```&lt;BR /&gt;[ &lt;BR /&gt;{ match_type: { '.tag': 'filename'},&lt;BR /&gt;&amp;nbsp; metadata: { '.tag': 'file', ...}&lt;BR /&gt;}&lt;BR /&gt;]&lt;BR /&gt;```&lt;/P&gt;
&lt;P&gt;Both&amp;nbsp;`_.pluck(results, 'match_type.tag')` and&amp;nbsp;`_.pluck(results, 'match_type..tag')` fail.&lt;/P&gt;
&lt;P&gt;Any filter is awkward: `list.filter( result =&amp;gt; result.metadata['.tag'] === 'folder' )`&lt;/P&gt;
&lt;P&gt;Any javascript/JSON api should not be using .'s, -'s, or spaces in attribute names. &amp;nbsp;Makes developing against it very kludgy.&lt;/P&gt;</description>
      <pubDate>Fri, 20 Nov 2015 01:49:51 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158906#M5396</guid>
      <dc:creator>Dan L.10</dc:creator>
      <dc:date>2015-11-20T01:49:51Z</dc:date>
    </item>
    <item>
      <title>Re: API v2 feedback: files' ".tag" attribute extremely unfriendly for HTTP/JSON</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158907#M5397</link>
      <description>&lt;P&gt;Thanks for the&amp;nbsp;feedback. This should work fine:&lt;/P&gt;
&lt;PRE&gt;_.pluck(results, 'match_type[".tag"]')&lt;/PRE&gt;</description>
      <pubDate>Fri, 20 Nov 2015 03:19:26 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158907#M5397</guid>
      <dc:creator>Steve M.</dc:creator>
      <dc:date>2015-11-20T03:19:26Z</dc:date>
    </item>
    <item>
      <title>Re: API v2 feedback: files' ".tag" attribute extremely unfriendly for HTTP/JSON</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158908#M5398</link>
      <description>&lt;P&gt;The [".tag"] selector was always a workaround,&amp;nbsp;the feedback is that a json API shouldn't have to resort to such fallbacks.&lt;/P&gt;
&lt;P&gt;Any chance of calling the ".tag" attribute deprecated and just duplicating the information under a more friendly attribute name so we can start&amp;nbsp;preparing for the next version of the API? &amp;nbsp;At the cost of some small redundancy, an approach like that won't break existing integrations while still providing a friendlier developer experience with the existing API.&lt;/P&gt;</description>
      <pubDate>Fri, 20 Nov 2015 03:33:18 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158908#M5398</guid>
      <dc:creator>Dan L.10</dc:creator>
      <dc:date>2015-11-20T03:33:18Z</dc:date>
    </item>
    <item>
      <title>Re: API v2 feedback: files' ".tag" attribute extremely unfriendly for HTTP/JSON</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158909#M5399</link>
      <description>&lt;P&gt;I'm passing this along, but I don't think we'll be making this change in API v2.&amp;nbsp;The lack of support for JavaScript's dot-notation syntactic sugar&amp;nbsp;is sort of by design. We&amp;nbsp;used a dot specifically&amp;nbsp;because it's not likely to&amp;nbsp;collide with anything else&amp;nbsp;(because&amp;nbsp;dots are uncommon in JSON dictionary keys).&lt;/P&gt;</description>
      <pubDate>Fri, 20 Nov 2015 03:42:05 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-v2-feedback-files-quot-tag-quot-attribute-extremely/m-p/158909#M5399</guid>
      <dc:creator>Steve M.</dc:creator>
      <dc:date>2015-11-20T03:42:05Z</dc:date>
    </item>
  </channel>
</rss>

