On Wed, Jan 16, 2013 at 3:13 PM, Sebastien Blanc <scm.blanc(a)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(a)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(a)redhat.com(mailto:
> kris(a)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(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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