[aerogear-dev] Paging Demo
Daniel Bevenius
daniel.bevenius at gmail.com
Fri Jan 11 07:32:40 EST 2013
>MO, if we are on the first page the Link-Previous header should be empty
since there is no previous page. That will make it easier for people
building the UI to know if they should show a previous link, etc.
Ah yeah, I agree. I'll change that.
>Also, you can't have two parameters with the same name, should that
actually be page=0&perPage=4?
Can't believe how I missed that. I'll fix that too.
Thanks!
On 11 January 2013 13:27, Kris Borchers <kris at redhat.com> wrote:
>
> On Jan 11, 2013, at 5:01 AM, Daniel Bevenius <daniel.bevenius at gmail.com>
> wrote:
>
> Hey Kris,
>
> been thinking about your reply regarding the inconsistency of the returned
> data. I think it looks a little odd to have the 'cars' property returned
> when requesting a single car.
> What do you all think of this as a suggestion below?
>
>
> I'm sorry, I misread that e-mail and thought these were both requests to
> the /cars endpoint and the data returned was formatted differently based on
> the data length. What you have makes sense so disregard what I said.
>
>
> As you can see we now return HTTP Headers and also the object returned is
> either an array of cars, or just a single object if you only request a
> single car.
>
> Getting a page of Cars
>
> URL="http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo"
> curl -i --header "Accept: application/json" "$URL/cars?page=0&perPage=4"
>
> The request will return:
>
> HTTP/1.1 200 OKLink-Previous: cars?page=0&page=4
>
> IMO, if we are on the first page the Link-Previous header should be empty
> since there is no previous page. That will make it easier for people
> building the UI to know if they should show a previous link, etc. Also, you
> can't have two parameters with the same name, should that actually be
> page=0&perPage=4?
>
> Link-First: cars?page=0&page=4
>
> Same thing, page/perPage?
>
> MetaData-PerPage: 4MetaData-Page: 0Link-Next: cars?page=1&page=4
>
> Same as previous, if we are on the last page, there should not be a value
> for Link-Next. Also, as above, page/perPage?
>
> Content-Type: application/json;charset=UTF-8Content-Length: 161[
> {"color":"Black","brand":"BMW","id":1},
> {"color":"Red","brand":"Ferrari","id":2},
> {"color":"Blue","brand":"Skoda","id":3},
> {"color":"Green","brand":"Audi","id":4}]
>
> <https://gist.github.com/4500336#getting-the-next-page-of-cars> Get a
> single Car
>
> URL="http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo"
> curl -i --header "Accept: application/json" "$URL/cars/1"
>
> The request will return:
>
> {"color":"Black","brand":"BMW","id":1}
>
>
>
> On 10 January 2013 20:00, Daniel Bevenius <daniel.bevenius at gmail.com>wrote:
>
>> Summers brought up a good point today on IRC which I've forgot to
>> mention. We've said that it will be possible to pass the page parameters as
>> HTTP Headers and this is still the plan. But the demo is using the lastest
>> from upstream and support for passing headers to the client is not there
>> yet. I hope to have this working shortly though and I'll post back with
>> information as soon as possible, tomorrow or Monday at the latest.
>>
>>
>>
>>
>> On 10 January 2013 15:32, Daniel Bevenius <daniel.bevenius at gmail.com>wrote:
>>
>>> >I know it's just a demo but I think making that JSON format consistent
>>> so that the car data is always in an array under the "cars" key would be
>>> better.
>>> Good point. I'll change this so that there is always a "cars' key.
>>>
>>>
>>> On 10 January 2013 15:13, Kris Borchers <kris at redhat.com> wrote:
>>>
>>>>
>>>> On Jan 10, 2013, at 3:02 AM, Daniel Bevenius <daniel.bevenius at gmail.com>
>>>> wrote:
>>>>
>>>> We talked about paging yesterday on IRC, and it was decided to add a
>>>> paging example to aerogear-controller-demo. What follows is an example to
>>>> kick of further discussion about what the example should look like.
>>>>
>>>> AeroGear Controller Demo Paging Route
>>>>
>>>> This page discusses AEROGEAR-795<https://issues.jboss.org/browse/AEROGEAR-795> which
>>>> is about adding an example to aerogear-controller-demo to demonstrate
>>>> paging support so that the client libraries (Android, JavaScript, and iOS)
>>>> can be tested against it.
>>>>
>>>> This is only a suggestion and the implementation and the names of the
>>>> query parameters can all be changed.
>>>> Use case
>>>>
>>>> The example is using cars as the resource to interact with. To be able
>>>> to query we need something to query, so lets start by adding some cars by
>>>> posting.
>>>> Adding Cars
>>>>
>>>> URL="http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo"
>>>>
>>>> curl -i --header "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" --data "car.color=Black&car.brand=BMW" -X POST "$URL/cars"
>>>> curl -i --header "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" --data "car.color=Red&car.brand=Ferrari" -X POST "$URL/cars"
>>>> curl -i --header "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" --data "car.color=Blue&car.brand=Skoda" -X POST "$URL/cars"
>>>> curl -i --header "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" --data "car.color=Green&car.brand=Audi" -X POST "$URL/cars"
>>>> curl -i --header "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" --data "car.color=Yello&car.brand=Opel" -X POST "$URL/cars"
>>>> curl -i --header "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" --data "car.color=Pink&car.brand=Mini" -X POST "$URL/cars"
>>>> curl -i --header "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" --data "car.color=Gray&car.brand=Nissan" -X POST "$URL/cars"
>>>> curl -i --header "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" --data "car.color=Red&car.brand=Volvo" -X POST "$URL/cars"
>>>> curl -i --header "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" --data "car.color=Blue&car.brand=Saab" -X POST "$URL/cars"
>>>> curl -i --header "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" --data "car.color=Black&car.brand=Mazda" -X POST "$URL/cars"
>>>> curl -i --header "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" --data "car.color=Yello&car.brand=Golf" -X POST "$URL/cars"
>>>>
>>>> The example uses an in-memory database so the data will be cleared upon
>>>> redployment/restart of the server. So you only need to populate/post when
>>>> you've restared or redployed.
>>>>
>>>> With the cars in place, we can now issue GET requests with paging query
>>>> parameters. The following route has been added to the demo:
>>>>
>>>> route()
>>>> .from("/cars")
>>>> .on(RequestMethod.GET)
>>>> .produces(MediaType.JSON.toString())
>>>> .to(Cars.class).get(param("page", "0"), param("perPage", "-1"));
>>>>
>>>> From this we can see that there are two optional parameters, page and
>>>> perPage. If these are not specified all cars will be returned.
>>>> Getting a page of Cars
>>>>
>>>> URL="http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo"
>>>> curl -i --header "Accept: application/json" "$URL/cars?page=0&perPage=4"
>>>>
>>>> The request will return:
>>>>
>>>> {
>>>> "metadata":{"page":0,"perPage":4},
>>>> "cars":[
>>>> {"color":"Black","brand":"BMW","id":1},
>>>> {"color":"Red","brand":"Ferrari","id":2},
>>>> {"color":"Blue","brand":"Skoda","id":3},
>>>> {"color":"Green","brand":"Audi","id":4}
>>>> ],
>>>> "links":{
>>>> "first":"cars?page=0&page=4",
>>>> "previous":"cars?page=0&page=4",
>>>> "next":"cars?page=1&page=4"
>>>> }}
>>>>
>>>> Getting the next page of Cars
>>>>
>>>> To get the next page you can follow the next link:
>>>>
>>>> URL="http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo"
>>>> curl -i --header "Accept: application/json" "$URL/cars?page=1&perPage=4"
>>>>
>>>> {
>>>> "metadata":{"page":1,"perPage":4},
>>>> "cars":[
>>>> {"color":"Yello","brand":"Opel","id":5},
>>>> {"color":"Pink","brand":"Mini","id":6},
>>>> {"color":"Gray","brand":"Nissan","id":7},
>>>> {"color":"Red","brand":"Volvo","id":8}
>>>> ],
>>>> "links":{
>>>> "first":"cars?page=0&page=4",
>>>> "previous":"cars?page=0&page=4",
>>>> "next":"cars?page=2&page=4"
>>>> }}
>>>>
>>>> Get all Cars
>>>>
>>>> URL="http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo"
>>>> curl -i --header "Accept: application/json" "$URL/cars"
>>>>
>>>> Get a single Car
>>>>
>>>> URL="http://controllerdemo-danbev.rhcloud.com/aerogear-controller-demo"
>>>> curl -i --header "Accept: application/json" "$URL/cars/1"
>>>>
>>>> The request will return:
>>>>
>>>> {"color":"Black","brand":"BMW","id":1}
>>>>
>>>>
>>>> Hmmm, the data returned should be consistent, right? Whether paging
>>>> parameters are supplied or not, the structure of the JSON to access the car
>>>> info should be the same. It's fine to leave out the metadata and links when
>>>> they're not needed I guess but to access the car info, currently you have:
>>>>
>>>> Not Paged: {"color":"Black","brand":"BMW","id":1}
>>>> Paged: {"cars":[{"color":"Black","brand":"BMW","id":1},…]}
>>>>
>>>> I know it's just a demo but I think making that JSON format consistent
>>>> so that the car data is always in an array under the "cars" key would be
>>>> better.
>>>>
>>>> Again, anything here can be changed, the name of the query parameters,
>>>> the implementation, and what is returned.
>>>>
>>>> Reference:
>>>>
>>>> - Paging Support in AeroGear Controller<https://gist.github.com/4147473>
>>>>
>>>> _______________________________________________
>>>> 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/20130111/302956ed/attachment-0001.html
More information about the aerogear-dev
mailing list