[aerogear-dev] Server Side: Paging API with Metadata and Links (was: Re: Paging Demo)
Sebastien Blanc
scm.blanc at gmail.com
Wed Jan 16 10:12:29 EST 2013
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130116/3acda82f/attachment-0001.html
More information about the aerogear-dev
mailing list