[aerogear-dev] Paging Metadata in Response Body

[Kris Borchers]

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