[aerogear-dev] Paging Metadata in Response Body

[Sebastien Blanc]

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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130122/46ace164/attachment.html