[aerogear-dev] Server Side: Paging API with Metadata and Links (was: Re: Paging Demo)

Daniel Bevenius daniel.bevenius at gmail.com
Wed Jan 16 10:19:37 EST 2013


>Is OffsetPagedResponse a class that implements ResponseHeaders ?
At the moment it is. We are still working on the server side, and will
probably make this an interface.

>About the name maybe just PagedResponse instead of OffsetPagedResponse ?
Yep, that sounds better.

Thanks,

/Dan


On 16 January 2013 16:12, Sebastien Blanc <scm.blanc at gmail.com> wrote:

> Is OffsetPagedResponse a class that implements ResponseHeaders ? About
> the name maybe just PagedResponse instead of OffsetPagedResponse ?
>
>
> On Wed, Jan 16, 2013 at 3:45 PM, Daniel Bevenius <
> daniel.bevenius at gmail.com> wrote:
>
>> Sorry about the spacing of code in my last post, you can see the source
>> here:
>>
>> https://github.com/danbev/aerogear-controller-demo/blob/AEROGEAR-795-paging-demo/src/main/java/org/jboss/aerogear/controller/demo/Cars.java#L82
>>
>>
>>
>>
>> On 16 January 2013 15:43, Daniel Bevenius <daniel.bevenius at gmail.com>wrote:
>>
>>> I'm trying to find an easy way for doing this and wondering what people
>>> things about something like this:
>>>
>>>
>>> public OffsetPagedResponse findCarsByBrand(final String offsetParam, final String limitParam) {
>>>
>>>
>>>         final int offset = Integer.valueOf(offsetParam);
>>>
>>>
>>>         final int limit = Integer.valueOf(limitParam);
>>>
>>>
>>>         final int total = getCarsTotal();
>>>
>>>
>>>         final List<Car> cars = getCars(offset, limit);
>>>
>>>
>>>
>>>         return Pagination.offset(offset)
>>>
>>>
>>>                 .limit(limit)
>>>
>>>
>>>                 .total(total)
>>>
>>>
>>>                 .resourcePath("cars")
>>>
>>>
>>>                 .headersPrefix("Demo-")
>>>
>>>
>>>                 .response(cars);
>>>
>>>
>>>     }
>>>
>>>
>>>
>>> On 14 January 2013 14:41, Douglas Campos <qmx at qmx.me> wrote:
>>>
>>>> Well, from reading the PR I really think this should be part of the
>>>> controller - something that decorates the return and sets appropriate
>>>> headers.
>>>>
>>>> a very high level usage example would be something like this:
>>>>
>>>> public List<Car> findCarsByFoo(Car example) {
>>>>     List<Car> cars = // does the magic
>>>>     return paginate(cars); // static helper that wraps this list on a
>>>> lightweight wrapper,
>>>>                            // that triggers the behavior
>>>> }
>>>>
>>>> Thoughts?
>>>>
>>>> Matzew already put this on our meeting agenda for today, but feel free
>>>> to send suggestions here :)
>>>>
>>>> -- qmx
>>>>
>>>> On 14/01/2013, at 07:30, Daniel Bevenius <daniel.bevenius at gmail.com>
>>>> wrote:
>>>>
>>>> > >if we add a dependency on the params into our client library, we
>>>> pretty much build against a "demo API".
>>>> > There should be no dependencies in the client APIs to these params or
>>>> headers. This is up the the implementation of the target Route and the
>>>> params names, the response headers could be anything they user wants. This
>>>> is just an example where we try to provide a good way of doing this. At
>>>> least this is my view of it.
>>>> >
>>>> > /Dan
>>>> >
>>>> >
>>>> > On 14 January 2013 10:28, Matthias Wessendorf <matzew at apache.org>
>>>> wrote:
>>>> > Looking at the PR for the demo ([1]) ,I am a bit surprised that
>>>> > classes like "Links.java" or "Metadata.java" are part of the demo
>>>> > code.
>>>> >
>>>> > I thought that the metadata/header informations on the response, like:
>>>> > ```
>>>> > AG-Paging-Offset: 1
>>>> > AG-Paging-Limit: 4
>>>> > AG-Paging-Total: 4
>>>> > AG-Links-First: cars?offset=0&limit=4
>>>> > AG-Links-Previous: cars?offset=0&limit=4
>>>> > AG-Links-Next: cars?offset=2&limit=4
>>>> > AG-Links-Last: cars?offset=3&limit=4
>>>> > ```
>>>> >
>>>> > are applied by the framework. Of course, the "cars" in there is app
>>>> > specific, but this information could be read out of the actual route
>>>> > (/cars).
>>>> >
>>>> > Not sure, but... if all the time we (end user) needs to (re)impl.
>>>> > these things... it could be a bit annoying.
>>>> >
>>>> >
>>>> > IMO the problem would be:
>>>> > - if we add a dependency on the params into our client libraries, we
>>>> > pretty much build against a "demo API". Which is odd...
>>>> > I thought these "metadata details" are offered by the framework.
>>>> >
>>>> > -M
>>>> >
>>>> > [1] https://github.com/aerogear/aerogear-controller-demo/pull/19
>>>> >
>>>> > On Sun, Jan 13, 2013 at 12:09 PM, Daniel Bevenius
>>>> > <daniel.bevenius at gmail.com> wrote:
>>>> > > I've updated the demo and think I've included all the requests.
>>>> > > * Pre-populate the database upon deployment of demo.
>>>> > > * Use 'offset/limit' instead of 'page/perPage'.
>>>> > > * Use 'AG-' prefix for headers.
>>>> > >
>>>> > > Let me know if you are missing anything, or would like something
>>>> done in a
>>>> > > different way.
>>>> > >
>>>> > > Use case
>>>> > >
>>>> > > The example is using /cars as the resource to interact with.
>>>> > >
>>>> > > The following route has been added to the demo:
>>>> > >
>>>> > > route()
>>>> > >       .from("/cars")
>>>> > >       .on(RequestMethod.GET)
>>>> > >       .produces(MediaType.JSON)
>>>> > >       .to(Cars.class).get(param("offset", "0"), param("limit",
>>>> "-1"));
>>>> > >
>>>> > > From this we can see that there are two optional parameters, offset
>>>> and
>>>> > > limit. If these are not specified all cars will be returned.
>>>> > >
>>>> > > Getting a page of Cars
>>>> > >
>>>> > > curl -i --header "Accept: application/json"
>>>> > > "
>>>> http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars?offset=0&limit=4
>>>> "
>>>> > >
>>>> > > The request will return:
>>>> > >
>>>> > > HTTP/1.1 200 OK
>>>> > > Content-Type: application/json;charset=UTF-8
>>>> > > Content-Length: 160
>>>> > > AG-Paging-Offset: 0
>>>> > > AG-Paging-Limit: 4
>>>> > > AG-Paging-Total: 4
>>>> > > AG-Links-Next: cars?offset=1&limit=4
>>>> > > AG-Links-Last: cars?offset=3&limit=4
>>>> > > [
>>>> > >   {"color":"Green","brand":"Audi","id":1},
>>>> > >   {"color":"White","brand":"Audi","id":2},
>>>> > >   {"color":"Black","brand":"Audi","id":3},
>>>> > >   {"color":"Black","brand":"BMW","id":4}
>>>> > > ]
>>>> > >
>>>> > > Getting the next page of Cars
>>>> > >
>>>> > > To get the next page you can follow the next link:
>>>> > >
>>>> > > curl -i --header "Accept: application/json"
>>>> > > "
>>>> http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars?offset=1&limit=4
>>>> "
>>>> > >
>>>> > > HTTP/1.1 200 OK
>>>> > > Content-Type: application/json;charset=UTF-8
>>>> > > Content-Length: 166
>>>> > > AG-Paging-Offset: 1
>>>> > > AG-Paging-Limit: 4
>>>> > > AG-Paging-Total: 4
>>>> > > AG-Links-First: cars?offset=0&limit=4
>>>> > > AG-Links-Previous: cars?offset=0&limit=4
>>>> > > AG-Links-Next: cars?offset=2&limit=4
>>>> > > AG-Links-Last: cars?offset=3&limit=4
>>>> > > [
>>>> > >    {"color":"Green","brand":"BMW","id":5},
>>>> > >    {"color":"Red","brand":"Ferrari","id":6},
>>>> > >    {"color":"White","brand":"Ferrari","id":7},
>>>> > >    {"color":"Pink","brand":"Ferrari","id":8}
>>>> > > ]
>>>> > >
>>>> > > Get all Cars
>>>> > >
>>>> > > curl -i --header "Accept: application/json"
>>>> > > "
>>>> http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars"
>>>> > >
>>>> > > This request will return:
>>>> > >
>>>> > > [
>>>> > >    {"color":"Green","brand":"Audi","id":1},
>>>> > >    {"color":"White","brand":"Audi","id":2},
>>>> > >    {"color":"Black","brand":"Audi","id":3},
>>>> > >    {"color":"Black","brand":"BMW","id":4},
>>>> > >    {"color":"Green","brand":"BMW","id":5},
>>>> > >    {"color":"Red","brand":"Ferrari","id":6},
>>>> > >    {"color":"White","brand":"Ferrari","id":7},
>>>> > >    {"color":"Pink","brand":"Ferrari","id":8},
>>>> > >    {"color":"White","brand":"Golf","id":15},
>>>> > >    {"color":"Brown","brand":"Lada","id":16},
>>>> > >    {"color":"Orange","brand":"Mazda","id":14},
>>>> > >    {"color":"Pink","brand":"Mini","id":13},
>>>> > >    {"color":"Gray","brand":"Nissan","id":11},
>>>> > >    {"color":"Yello","brand":"Opel","id":10},
>>>> > >    {"color":"Blue","brand":"Scoda","id":9},
>>>> > >    {"color":"Red","brand":"Volvo","id":12}
>>>> > > ]
>>>> > >
>>>> > > Get a single Car
>>>> > >
>>>> > > curl -i --header "Accept: application/json"
>>>> > > "
>>>> http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo/cars/1
>>>> "
>>>> > >
>>>> > > The request will return:
>>>> > >
>>>> > > {"color":"Green","brand":"Audi","id":1}
>>>> > >
>>>> > >
>>>> > >
>>>> > > On 12 January 2013 11:08, Daniel Bevenius <
>>>> daniel.bevenius at gmail.com> wrote:
>>>> > >>
>>>> > >> Great, lets go with 'AG-' prefix then.
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >> On 11 January 2013 18:24, Douglas Campos <qmx at qmx.me> wrote:
>>>> > >>>
>>>> > >>>
>>>> > >>> On 11/01/2013, at 15:10, Kris Borchers <kris at redhat.com> wrote:
>>>> > >>> > I guess what I meant is I'm not specifically +1 for X- prefix
>>>> but just
>>>> > >>> > some sort of prefix in general. It just makes it easier for
>>>> devs when
>>>> > >>> > looking through headers to see what is being sent. Even
>>>> something like AG-
>>>> > >>> > or AeroGear- would be better IMO than no prefix.
>>>> > >>>
>>>> > >>> d'oh, +1 - thought I've typed it…
>>>> > >>>
>>>> > >>> AG- looks nicer - less bandwidth ;)
>>>> > >>>
>>>> > >>> -- qmx
>>>> > >>> _______________________________________________
>>>> > >>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130116/e1543892/attachment-0001.html 


More information about the aerogear-dev mailing list