On Thu, Jan 17, 2013 at 8:47 AM, Daniel Bevenius
<daniel.bevenius(a)gmail.com> wrote:
>perhaps I don't get it - but... our backend uses the headers
for the web
> linking, AG-Limit etc, right?
Yeah, you are correct our backend is using headers for web linking and
total. We discussed [1] in the past the option to have the same information
in the body of the response instead of as HTTP headers, for example an
Object in a JSON response. The location of this information could then be
specified by the client to tell the server where it should place the
metadata.
hrm... not sure I like that. This could wait for a later release. I am
(personally) fine
in supporting just one location (and our clients should default to it).
>I think, it's OK to NOT send that limit/offset overhead to
someone
>that knows about it already. That's what you are saying, right ?
Yep, so we would just return the 'AG-Total' in this case.
[1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Paging-Demo-td1173...
On 17 January 2013 08:36, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
> On Thu, Jan 17, 2013 at 8:05 AM, Daniel Bevenius
> <daniel.bevenius(a)gmail.com> wrote:
> > I've been reading the client API spec and noticed that I completely
> > forgot
> > the parameter 'metadataLocation' that an endpoint could optionally
> > accept,
> > which indicates if the information related to paging should be returned
> > as
> > part of the data, or as HTTP Headers.
> > I'll update the server side spec if no one objects.
>
> perhaps I don't get it - but... our backend uses the headers for the
> web linking, AG-Limit etc, right?
>
> So why should we include a "location" header? I understood it more as
> a "generic" client feature:
> - Tell the pipe where (haha :-)) to look (page/content VS header) for
> the "next", "previous" etc information
>
>
> > I also wanted to bring up that in the spec at the moment we have
> > specified
> > that we are only returning the 'total', and not the 'offset'
and
> > 'limit'.
> > The reason for this being that the client sent the 'offset' and
'limit'
> > and
> > therefore already has this information. Does anyone have a different
> > take on
> > this?
>
> I think, it's OK to NOT send that limit/offset overhead to someone
> that knows about it already. That's what you are saying, right ?
>
> -M
>
> >
> > thanks,
> >
> > /Dan
> >
> >
> >
> >
> > On 15 January 2013 19:44, Daniel Bevenius <daniel.bevenius(a)gmail.com>
> > wrote:
> >>
> >> +1 I'll start adding it tomorrow and keep it updated if no one objects.
> >>
> >>
> >> On 15 January 2013 19:42, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
> >>>
> >>> +1
> >>>
> >>>
> >>> On Tue, Jan 15, 2013 at 7:37 PM, Bruno Oliveira
<bruno(a)abstractj.org>
> >>> wrote:
> >>>>
> >>>> +1 Any additions?
> >>>>
> >>>> I just wondering about include it at
> >>>>
http://aerogear.org/docs/specs/aerogear-rest-api/. Makes sense?
> >>>>
> >>>>
> >>>> --
> >>>> "The measure of a man is what he does with power" - Plato
> >>>> -
> >>>> @abstractj
> >>>> -
> >>>> Volenti Nihil Difficile
> >>>>
> >>>> On Tuesday, January 15, 2013 at 11:18 AM, Kris Borchers wrote:
> >>>>
> >>>> This looks pretty good to me.
> >>>>
> >>>> On Jan 15, 2013, at 3:26 AM, Daniel Bevenius
> >>>> <daniel.bevenius(a)gmail.com>
> >>>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> we've created the following gist[1] to specify our requirements
for
> >>>> pagination. We can discuss this on the mailing list and then update
> >>>> the doc
> >>>> as we go along. This will later be turned into a page under the
spec
> >>>> section
> >>>> of the site.
> >>>>
> >>>> Nothing has been decide yet even if it might read like it has in
the
> >>>> document.
> >>>>
> >>>> [1]
https://gist.github.com/4537431
> >>>> _______________________________________________
> >>>> 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
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>
> >
> >
> > _______________________________________________
> > 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