11:32 a.m.
Hi,
There's a growing portion of application code in the metrics REST API
which returns errors (with whichever HTTP status) in the following form:
====
{"errorMsg": "blah"}
====
Whether this format is nice or suitable is not the purpose of this
message. I just want to draw your attention to the fact that being
consistent regarding error reporting is important.
In this regard, I've added a new ExceptionMapper for
org.jboss.resteasy.spi.ReaderException[2] instances. So now, not only
application errors conform to the format above, but also errors coming
from payload parsing.
Regards,
Thomas
[1]
http://docs.jboss.org/resteasy/docs/3.0.9.Final/userguide/html_single/#bu...
3:37 a.m.
Hello,
Thanks for opening this issue again. I think we should follow a standard
here. Let me just copy-paste from my last email (Thread "REST ideas"):
Another REST issue we should agree on: The standard for error responses.
I've found, that there are several standards we can follow (or create
our own):
http://stackoverflow.com/a/14538774/3252949
In my opinion it's fine to stick with the JSON API:
http://jsonapi.org/format/#errors
or stick with even simpler google style guide:
https://google-styleguide.googlecode.com/svn/trunk/jsoncstyleguide.xml?sh...
Viliam
On Thu, 2015-03-05 at 18:32 +0100, Thomas Segismont wrote:
Hi,
There's a growing portion of application code in the metrics REST API
which returns errors (with whichever HTTP status) in the following form:
====
{"errorMsg": "blah"}
====
Whether this format is nice or suitable is not the purpose of this
message. I just want to draw your attention to the fact that being
consistent regarding error reporting is important.
In this regard, I've added a new ExceptionMapper for
org.jboss.resteasy.spi.ReaderException[2] instances. So now, not only
application errors conform to the format above, but also errors coming
from payload parsing.
Regards,
Thomas
[1]
http://docs.jboss.org/resteasy/docs/3.0.9.Final/userguide/html_single/#bu...
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:48 a.m.
I'm fine with something simple to begin with.
Really, the purpose of my email was to recall we're running on top of a
container+framework and that application errors are not the only ones.
Le 06/03/2015 10:37, Viliam Rockai a écrit :
Hello,
Thanks for opening this issue again. I think we should follow a standard
here. Let me just copy-paste from my last email (Thread "REST ideas"):
Another REST issue we should agree on: The standard for error responses.
I've found, that there are several standards we can follow (or create
our own):
http://stackoverflow.com/a/14538774/3252949
In my opinion it's fine to stick with the JSON API:
http://jsonapi.org/format/#errors
or stick with even simpler google style guide:
https://google-styleguide.googlecode.com/svn/trunk/jsoncstyleguide.xml?sh...
Viliam
On Thu, 2015-03-05 at 18:32 +0100, Thomas Segismont wrote:
> Hi,
>
> There's a growing portion of application code in the metrics REST API
> which returns errors (with whichever HTTP status) in the following form:
>
> ====
> {"errorMsg": "blah"}
> ====
>
> Whether this format is nice or suitable is not the purpose of this
> message. I just want to draw your attention to the fact that being
> consistent regarding error reporting is important.
>
> In this regard, I've added a new ExceptionMapper for
> org.jboss.resteasy.spi.ReaderException[2] instances. So now, not only
> application errors conform to the format above, but also errors coming
> from payload parsing.
>
> Regards,
> Thomas
>
> [1]
>
http://docs.jboss.org/resteasy/docs/3.0.9.Final/userguide/html_single/#bu...
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:57 a.m.
We should all over the place
a) specifc exceptions for some of the more common cases
like StuffNotFoundException(message)
b) add Exception mappers that deal with mapping that exception content to some sensible
output depending on requested media type.
We have done that in RHQ, which could for the start be copied 1:1.
See
https://github.com/rhq-project/rhq/blob/master/modules/enterprise/server/...
and
https://github.com/rhq-project/rhq/blob/master/modules/enterprise/server/...
and
https://github.com/rhq-project/rhq/blob/master/modules/enterprise/server/...
Am 05.03.2015 um 18:32 schrieb Thomas Segismont
<tsegismo(a)redhat.com>:
Hi,
There's a growing portion of application code in the metrics REST API
which returns errors (with whichever HTTP status) in the following form:
====
{"errorMsg": "blah"}
====
Whether this format is nice or suitable is not the purpose of this
message. I just want to draw your attention to the fact that being
consistent regarding error reporting is important.
In this regard, I've added a new ExceptionMapper for
org.jboss.resteasy.spi.ReaderException[2] instances. So now, not only
application errors conform to the format above, but also errors coming
from payload parsing.
Regards,
Thomas
[1]
http://docs.jboss.org/resteasy/docs/3.0.9.Final/userguide/html_single/#bu...
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
4:07 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/06/2015 10:57 AM, Heiko W.Rupp wrote:
We should all over the place
a) specifc exceptions for some of the more common cases like
StuffNotFoundException(message)
b) add Exception mappers that deal with mapping that exception
content to some sensible output depending on requested media type.
I think we should be a bit careful with blindly throwing exceptions
and mapping them to responses. Exceptions are more expensive than just
checking for an object's existence and, for a public service (SaaS),
this could be abused.
For scenarios where things were really expected to be there but
aren't, exceptions are fine. For scenarios where the user asked for
something that didn't exist, input checking and promptly returning a
404 makes more sense, IMO.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU+Xx6AAoJECKM1e+fkPrXcjsH/2oX5F8HIcz9a29km8hSGBY2
/iPdHDmOA/WkdB/75T29oTdaVqKQkDonqHOsVC/GkBGNedJcWhnrdkN+08KZvseH
nED3e9EcKjY833jK1/1r4muPHNmDxGkE91AtsOGdQDo95ckDtqSH2qnJQns9GHZ5
qYohcKWFMZpD42upcYRaOyQTJBrN79WSwnoiijeTmb+OE4UoGIpRM/L2QS3lPcCq
4SMW2NuXJW06cm5OJTnfoc590JOf7fRkQakzA+W22GxE4INdkL95fQGS+Zoxp0cv
8ITUM4Ek1eyBc+LXMh0xB4P5mLGbiuoyD9l6oxC9w7vDOp8e2UGTRASdNiKwxSc=
=YcB3
-----END PGP SIGNATURE-----
4:17 a.m.
Le 06/03/2015 11:07, Juraci Paixão Kröhling a écrit :
I think we should be a bit careful with blindly throwing exceptions
and mapping them to responses. Exceptions are more expensive than just
checking for an object's existence and, for a public service (SaaS),
this could be abused.
For scenarios where things were really expected to be there but
aren't, exceptions are fine. For scenarios where the user asked for
something that didn't exist, input checking and promptly returning a
404 makes more sense, IMO.
+1
4:55 a.m.
Le 06/03/2015 11:07, Juraci Paixão Kröhling a écrit :
> I think we should be a bit careful with blindly throwing exceptions
> and mapping them to responses. Exceptions are more expensive than just
> checking for an object's existence and, for a public service (SaaS),
> this could be abused.
>
> For scenarios where things were really expected to be there but
> aren't, exceptions are fine. For scenarios where the user asked for
> something that didn't exist, input checking and promptly returning a
> 404 makes more sense, IMO.
+1
+1
5:11 a.m.
Am 06.03.2015 um 11:07 schrieb Juraci Paixão Kröhling
<jpkroehling(a)redhat.com>:
For scenarios where things were really expected to be there but
aren't, exceptions are fine. For scenarios where the user asked for
something that didn't exist, input checking and promptly returning a
404 makes more sense, IMO.
I fear that this will lead to pretty unreadable code with many blocks of
return Response.Builder.notFound(new StringEntity("this is my message
%s",bla)).type("application/json").build()
While we do (only) application/json right now, this will get more complex with more
(custom) media types.
5:30 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/06/2015 12:11 PM, Heiko W.Rupp wrote:
> Am 06.03.2015 um 11:07 schrieb Juraci Paixão Kröhling
> <jpkroehling(a)redhat.com>: For scenarios where things were really
> expected to be there but aren't, exceptions are fine. For
> scenarios where the user asked for something that didn't exist,
> input checking and promptly returning a 404 makes more sense,
> IMO.
I fear that this will lead to pretty unreadable code with many
blocks of
return Response.Builder.notFound(new StringEntity("this is my
message %s",bla)).type("application/json").build()
While we do (only) application/json right now, this will get more
complex with more (custom) media types.
How about then making beans for representing the responses and letting
the JAX-RS convert it to the appropriate media type? The disadvantage
is that each "response" structure requires a class. The advantage is
that it's well documented what is the response's structure.
class ErrorResponseBean {
String message;
}
ResponseBean bean = new ErrorResponseBean("this is my message %s",bla);
Response.notFound().entity(bean).build();
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU+Y/HAAoJECKM1e+fkPrXKLUH/2RYlwMACfK42JODX4w3BAc4
Lj1c4ObCkgHvLtP11/m8nA+HZwegFVqqJQZSYji3q9WYfLPBsQeRJv9Yciii5VnE
UaqxGwPRyxx6nVluPK4gBX8qirKFZh05kM6vRAotjYtnK8+BnxnEb38UmYVuhFL6
HIglliwtVqIK9CWmUn7atPCK7d6o0k3/xC1Kh0435dv85evC0kVr8w7eORC1iWjF
EBoHOvdYHl+rrvsOJyIXZERxhVhx4JD/gydsvKD5IBc4Q38fI0yXVtQdutsaufpW
CEwI2SrSZjZ9T2J9oVRUT8KgD/9GPNwTjGCmVu1e4tAq/yR57pj0OoY7gpjf640=
=+Q8p
-----END PGP SIGNATURE-----
5:56 a.m.
Hi,
This is what's done in the websocket branch currently:
@Override
public void onFailure(Throwable t) {
Error errors = new Error(errorMsg + ": " +
Throwables.getRootCause(t).getMessage());
response.resume(Response.status(Response.Status.INTERNAL_SERVER_ERROR).entity(errors).type(
MediaType.APPLICATION_JSON_TYPE).build());
}
public class Error {
private String errorMsg;
..
Currently with forced JSON.
- Micke
----- Original Message -----
From: "Juraci Paixão Kröhling" <jpkroehling(a)redhat.com>
To: hawkular-dev(a)lists.jboss.org
Sent: Friday, March 6, 2015 1:30:15 PM
Subject: Re: [Hawkular-dev] [metrics] Consistent error replies from REST API
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/06/2015 12:11 PM, Heiko W.Rupp wrote:
> Am 06.03.2015 um 11:07 schrieb Juraci Paixão Kröhling
> <jpkroehling(a)redhat.com>: For scenarios where things were really
> expected to be there but aren't, exceptions are fine. For
> scenarios where the user asked for something that didn't exist,
> input checking and promptly returning a 404 makes more sense,
> IMO.
I fear that this will lead to pretty unreadable code with many
blocks of
return Response.Builder.notFound(new StringEntity("this is my
message %s",bla)).type("application/json").build()
While we do (only) application/json right now, this will get more
complex with more (custom) media types.
How about then making beans for representing the responses and letting
the JAX-RS convert it to the appropriate media type? The disadvantage
is that each "response" structure requires a class. The advantage is
that it's well documented what is the response's structure.
class ErrorResponseBean {
String message;
}
ResponseBean bean = new ErrorResponseBean("this is my message %s",bla);
Response.notFound().entity(bean).build();
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU+Y/HAAoJECKM1e+fkPrXKLUH/2RYlwMACfK42JODX4w3BAc4
Lj1c4ObCkgHvLtP11/m8nA+HZwegFVqqJQZSYji3q9WYfLPBsQeRJv9Yciii5VnE
UaqxGwPRyxx6nVluPK4gBX8qirKFZh05kM6vRAotjYtnK8+BnxnEb38UmYVuhFL6
HIglliwtVqIK9CWmUn7atPCK7d6o0k3/xC1Kh0435dv85evC0kVr8w7eORC1iWjF
EBoHOvdYHl+rrvsOJyIXZERxhVhx4JD/gydsvKD5IBc4Q38fI0yXVtQdutsaufpW
CEwI2SrSZjZ9T2J9oVRUT8KgD/9GPNwTjGCmVu1e4tAq/yR57pj0OoY7gpjf640=
=+Q8p
-----END PGP SIGNATURE-----
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3583
days inactive
3584
days old
9 comments
6 participants
participants (6)
-
Heiko W.Rupp -
Juraci Paixão Kröhling -
Lucas Ponce -
Michael Burman -
Thomas Segismont -
Viliam Rockai