[aerogear-dev] Pagination Requirements Spec

[Matthias Wessendorf]

On Thu, Jan 17, 2013 at 8:47 AM, Daniel Bevenius
<daniel.bevenius at 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.

great :)

>
> [1]
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Paging-Demo-td1173.html
>
>
> On 17 January 2013 08:36, Matthias Wessendorf <matzew at apache.org> wrote:
>>
>> On Thu, Jan 17, 2013 at 8:05 AM, Daniel Bevenius
>> <daniel.bevenius at 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 at 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 at gmail.com> wrote:
>> >>>
>> >>> +1
>> >>>
>> >>>
>> >>> On Tue, Jan 15, 2013 at 7:37 PM, Bruno Oliveira <bruno at 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 at 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 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
>> >>>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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