[aerogear-dev] Paging Metadata in Response Body

[Kris Borchers]

So should we assume paging metadata is at the root and data is under a "results" key? (Like Twitter)

On Jan 22, 2013, at 8:56 AM, Kris Borchers <kris at redhat.com> wrote:

> 
> On Jan 22, 2013, at 3:50 AM, Matthias Wessendorf <matzew at apache.org> wrote:
> 
>> On Tue, Jan 22, 2013 at 10:37 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>> Interesting point Kris !
>>> Not sure how we can provide a simple and robust solution that works for all
>>> the cases. Maybe as you said, we follow a convention, that the info is at
>>> the root and otherwise the developer could use a custom function (as we do
>>> for sending paging info) to consume lpaging metadata.
>> 
>> yeah - something like a "provider" (function would work).
> 
> I think I can get on board with that.
>> 
>> We can't catch every server API :)
>> 
>>> Seb
>>> 
>>> 
>>> On Tue, Jan 22, 2013 at 7:49 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>> 
>>>> On Mon, Jan 21, 2013 at 10:23 PM, Kris Borchers <kris.borchers at gmail.com>
>>>> wrote:
>>>>> [Reposting from GMail because Red Hat account is blocked again]
>>>>> Thinking more, we could probably just keep the defaults undefined, that
>>>>> way they only define if they need them, otherwise the root of the response
>>>>> is assumed which would probably work better since for example, Twitter
>>>>> encapsulates the data but the paging is at the root of the response.
>>>>> 
>>>> 
>>>> Ah... ok, thanks for the example - I ran into that yesterday evening
>>>> as well, when testing parsing of the TW info...
>>>> 
>>>> Here is, I think, what you define "result container"
>>>> {
>>>>   "next_page": "some value..",
>>>>   "prev_page": "moar value...",
>>>> ...
>>>> more 'flat' data....
>>>> ...
>>>> }
>>>> 
>>>> There is a flat JSON response, that has the desired values at the root
>>>> level of the response.
>>>> 
>>>> Yesterday, I was wondering if there are server that do a more
>>>> structured (think Java/XML) response
>>>> {
>>>>   "metadata": {
>>>>       "next_page": "some value..",
>>>>       "prev_page": "moar value...",
>>>>               // other metadata....
>>>>   },
>>>>       /// more structured results...
>>>> }
>>>> 
>>>> So yeah... that does not work, right now...  But what happens if they
>>>> have even a bit deeper nesting (you never know why...).... I am now
>>>> just thinking XPath :) but I see your point, since I had that same
>>>> thought yesterday, after parsing twitters bits.
>>>> 
>>>> 
>>>> -M
>>>> 
>>>> 
>>>> 
>>>>> On Jan 21, 2013, at 3:19 PM, Kris Borchers <kris at redhat.com> wrote:
>>>>> 
>>>>>> I've hit one small snag. If the paging metadata is returned in the
>>>>>> body, it would probably be useful for the developer to be able to specify a
>>>>>> "paging container" and/or a "results container" since each of those pieces
>>>>>> of information would probably be encapsulated from the other in any sane
>>>>>> server implementation. I would suggest something like metadataContainer and
>>>>>> dataContainer with defaults of "paging" and "data" as defaults but I am
>>>>>> totally flexible on those.
>>>>>> 
>>>>>> Thoughts?
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Matthias Wessendorf
>>>> 
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>> 
>> 
>> 
>> -- 
>> Matthias Wessendorf
>> 
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev