[aerogear-dev] Paging Metadata in Response Body

[Matthias Wessendorf]

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).

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