Ability to 'omit' certain part of info from the returned data objects:

[kosso]

I'd love to be able to request to OMIT certain parts of the data retrieved.

eg: My mobile app does not use the 'html' section of a post object.

That's quite a lot of characters I could do without being in my returned JSON.

[dch]

This is similar (in reverse) to the JSON PATCH proposal - send me, or update, a segment of a path insides the JSON object. The syntax could be a useful reference: http://tools.ietf.org/html/draft-pbryan-json-patch-04

On 17 August 2012 17:37, Kosso notifications@github.com wrote:

I'd love to be able to request to OMIT certain parts of the data retrieved.

eg: My mobile app does not use the 'html' section of a post object.

That's quite a lot of characters I could do without being in my returned JSON.

— Reply to this email directly or view it on GitHubhttps://github.com/appdotnet/api-spec/issues/96.

[kosso]

I like that too.

I'm thinking more along the lines of a 'fields' parameter - similar to how Google does it, to obtain a partial response. see : https://developers.google.com/+/api/

[sperte]

Facebook's Graph API has this, too -- a fields parameter that allows you to systematically select certain fields. This, in conjunction with field groups would be awesome. Something like [request]?fields=for_mobile

[kosso]

I'm trying to bump this again. This is becoming a quite serious issue for mobile users. For all three main streams to load 50 posts each (for example) takes approx 400-500Kb of data! That's just crazy.

I really, really don't want all that data coming in to an app and using up valuable mobile data.

The 'html' part of the post (and user.description) are simply not required by most apps (I would say).

I really really need a way to decide which parts of the post and user objects I want included in the results.

Another example was that a repost (which also now carries the 'repost_of' section) of a 9 character post, by a person with a single character username was 8kb worth for data. Sorry, but this is kind of overkill.

I know a lot of that data is extremely useful and cuts down further API calls, but we need an option please.

Thanks.

Your customer, Kosso :P

[berg]

Definitely intend to do this. As I said to @mattflaschen earlier, the biggest thing is deciding upon a not-insane way to indicate what you do and don't want, that has enough simplicity to be easy to understand and enough complexity to actually be useful and worth the time to implement.

[berg]

It now occurs to me that the code we wrote for expressing filters in JSON could be useful here.

[kosso]

The Facebook and Google Plus APIs use a comma delimited list of fields to provide a partial response.

eg : https://developers.google.com/+/api/latest/people/get#try-it and : https://developers.facebook.com/docs/reference/api/ ('Selection')

That's basically what I'd like. ;)

K

On 15 November 2012 21:24, Bryan Berg notifications@github.com wrote:

It now occurs to me that the code we wrote for expressing filters in JSON could be useful here.

— Reply to this email directly or view it on GitHubhttps://github.com/appdotnet/api-spec/issues/96#issuecomment-10426114.

[kosso]

.. also note the way that Google Plus slash/field delimits the object/field too.

The main reason I'd like to see this functionality is to remove the 'bandwidth fluff' from the Post and User objects. (eg: html, etc.)

On 15 November 2012 21:32, Kosso kosso1@gmail.com wrote:

The Facebook and Google Plus APIs use a comma delimited list of fields to provide a partial response.

eg : https://developers.google.com/+/api/latest/people/get#try-it and : https://developers.facebook.com/docs/reference/api/ ('Selection')

That's basically what I'd like. ;)

K

On 15 November 2012 21:24, Bryan Berg notifications@github.com wrote:

It now occurs to me that the code we wrote for expressing filters in JSON could be useful here.

— Reply to this email directly or view it on GitHubhttps://github.com/appdotnet/api-spec/issues/96#issuecomment-10426114.

[berg]

The Facebook example is a no-go, because from what I remember it only lets you change top-level objects, and I assume you'd like to be able to remove HTML from both post and user bio.

The G+ example is more sane, but since we already have a query language for filters, I bet we can reuse that... probably will take a few weeks but I'll see what we can come up with.

[kosso]

Yup. Agreed. (hence the second post about the object masking, after a closer look)

.. which I suppose is indeed what you're doing with the stream filters. ;)

On 15 November 2012 21:41, Bryan Berg notifications@github.com wrote:

The Facebook example is a no-go, because from what I remember it only lets you change top-level objects, and I assume you'd like to be able to remove HTML from both post and user bio.

The G+ example is more sane, but since we already have a query language for filters, I bet we can reuse that... probably will take a few weeks but I'll see what we can come up with.

— Reply to this email directly or view it on GitHubhttps://github.com/appdotnet/api-spec/issues/96#issuecomment-10426747.