[aerogear-dev] Paging Metadata in Response Body

[Matthias Wessendorf]

On Tue, Jan 22, 2013 at 4:10 PM, Kris Borchers <kris at redhat.com> wrote:
> So should we assume paging metadata is at the root

for now yeah ...

> and data is under a "results" key? (Like Twitter)

for iOS not a bit deal, we deliver the entire reponse :)

>
> 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
>
>
> _______________________________________________
> 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