[aerogear-dev] Server Side: Paging API with Metadata and Links (was: Re: Paging Demo)
Daniel Bevenius
daniel.bevenius at gmail.com
Wed Jan 16 09:45:04 EST 2013
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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130116/0f036750/attachment-0001.html
More information about the aerogear-dev
mailing list