On Wed, Jan 16, 2013 at 3:01 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Jan 16, 2013, at 7:58 AM, 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.
I would prefer that an exception is thrown client side before a request is
ever sent to the server. That way we save the http request which is
important on mobile.
Ah! yeah - good point -> since the "paging API" knows there is no
"next"
(for instance)
That being said, then the issue becomes what if that page does exist but
we don't allow the request because the data was updated since our last
read? Then we wouldn't know without another read happening.
yeah - here could the 2.x targeted feature of 'sync' come in...
Hmmm, interested in other opinions since relying on a 204 or any status
from the server couples the client to the server impl but if we don't allow
the request, that could also cause issues.
true :)
--
"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@redhat.com <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<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