On Wed, Jan 16, 2013 at 3:13 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:
I agreed on not interrupt the workflow (although if exception are meant to be handelt in order to maintain the flow under some conditions).
HTTP 204 is a good option but is maybe more an impl details ? Because, in the future, when we will have offline/native paging, http status won't make a lot of sense, no ? 


well, the server (for pipe based paging) would sent the 204 - I like that idea. The client would use that, to "indicate" -> no data
(it COULD throw an execption (or invoke the failure callback (Android/iOS).


Offline, yeah - 204 makes no sense there, but the underlying storage would indicate differently, there is no "previous", and the "offline paging" could trhow an exception (or invoke a failure callback)

-M


 


On Wed, Jan 16, 2013 at 2:58 PM, Bruno Oliveira <bruno@abstractj.org> wrote:
If the data doesn't exist HTTP 204 is a good fit. Just don't understand why we need to interrupt the app workflow, because the data doesn't exist.


--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile



On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote:

>
> On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris@redhat.com (mailto:kris@redhat.com)> wrote:
> > I would say returning the current page would be confusing. I would be fine with an exception or returning null as both can be handled pretty easily by a dev. I would say an exception may be more useful since it will tell the dev exactly what was wrong instead of their app choking in a null return but I am open to both.
> >
> > >
> > > For offset > totalNbPages :
> > > - throwing an exception ?
> > > - returning null ?
> > > - returning last page ?
> >
> >
> >
> > I would say same as above. Returning last page may be confusing but others are acceptable with a preference toward an exception.
>
>
> +1 on an exception
>
> -M
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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