Re: [aerogear-dev] Pagination Requirements Spec

hrm... not sure I like that. This could wait for a later release. I am (personally)

On Thu, Jan 17, 2013 at 8:47 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; 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. great :) > > [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&gt; wrote: >> >> On Thu, Jan 17, 2013 at 8:05 AM, Daniel Bevenius >> <daniel.bevenius(a)gmail.com&gt; 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&gt; >> > 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&gt; wrote: >> >>> >> >>> +1 >> >>> >> >>> >> >>> On Tue, Jan 15, 2013 at 7:37 PM, Bruno Oliveira < bruno(a)abstractj.org&gt; >> >>> 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&gt; >> >>>> 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 > -- 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