Re: [aerogear-dev] Paging Metadata in Response Body

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.

Seb On Tue, Jan 22, 2013 at 7:49 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > On Mon, Jan 21, 2013 at 10:23 PM, Kris Borchers <kris.borchers(a)gmail.com&gt; > 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(a)redhat.com&gt; 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(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev