[aerogear-dev] Pagination Requirements Spec

Thu Jan 17 03:12:46 EST 2013

On Thu, Jan 17, 2013 at 9:05 AM, Daniel Bevenius
<daniel.bevenius at gmail.com> wrote:
>>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'm cool with that and like I said, this has not been included in the server
> side spec yet.

ok

> If we decide to wait until a later release we should remove
> this from the client api spec.

How would you tell the client (when removing) to look in the payload
for the next link (identified by "twitter-rel-next")?

The idea is, to say (when starting a "paged request"): Once you have
the first set, look in the content/response for a "twitter-rel-next"
JSON key.

If we remove that, the client would be tied to our server and could
not be used against Twitter's search API, to reuse Kris' example

-M

>
>
> On 17 January 2013 08:56, Matthias Wessendorf <matzew at apache.org> wrote:
>>
>> 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
>> _______________________________________________
>> 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