Re: JAX RS exceptions with illegal QueryParameter
Le 7 août 09 à 00:19, Nicolas Rinaudo a écrit : I haven't tested it myself, but I'm not sure that ExceptionMappers actually kick-in for exceptions triggered by the underlying Engine. I think it does, but a test would be needed to confirm. Regardless of that consideration though, the WebApplicationException thrown in such cases is just a generic one with a 404 status code. Even if I could write an ExceptionMapper to catch it, there'd be no way for me to differentiate it from other 404s. Well, let me rephrase that. I don't see how I'd go about differentiating it, but I'd love to hear your thoughts on the subject :) Yes, if the exception you get is just a generic one, it'll be hard! I was (optimistically) conjecturing some additional information might be provided (e.g. in the exception message, or in the exception cause). If not, then one approach is to implement the method that handles the request (e.g., annotated with @Path). From there, you could determine yourself if there is a client error in the params and throw an exception stuffed with an entity describing the problem. Best, Philippe Mougin -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2381304
Re: JAX RS exceptions with illegal QueryParameter
Hi Nicolas,
This might be a silly question, but is there a way to configure how the JAX
RS extention will react to illegal values for @QueryParameter annotated
parameters?
Say for example that you have a @QueryParameter(count) int count field and
that a client sets the value of the parameter to zorglub. This is obviously
not a legal integer and the JAX RS specifications tell us that this should be
dealt with by returning a 404 error code.
This makes sense when query parameters are part of the path. There are lots
of cases however where this error code is just not correct. Imagine for
example that your REST application serves reports. You'd typically have
/reports to serve all available reports and /reports/{id} to serve an
individual report.
In this case, it's fairly common to accept query parameters in /reports as
filters to the list of reports (number of items, author name, creation date
min). Returning a 404 when one of these parameters is just not correct
and we should return 400 (the resource was found, but the request was bad).
Do you mean you want to request something like /reports?lastname=smith
or /reports/4?lastname=smith?
/reports and /reports/68, /reports?lastname=smith and
/reports/68?lastname=smith are 4 different resources. So error doe 404
is right. But perhaps I misunderstood your scenario.
Is there any way to override the default error code, or do we have to
retrieve each parameter as a string and do the analysis ourselves? It seems
to somewhat defeat the purpose of the mechanism...
No, it is not possible now. Formally the HTTP specification allows no
freedom of interpretation.
best regards
Stephan
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2380720
RE: Re: JAX RS exceptions with illegal QueryParameter
From your answer, I think I might be misunderstanding the basic concept of a resource. The way I understand it is, if you have a /reports resource that lists all available reports and accepts a count parameter that limits the number of reports returned in a given query, /reports?count=10 and /reports?count=20 are the same resource. With that in mind, /reports?count=foobar isn't a 404 (the reports resource was found) but a 400 (query parameter 'count' has an illegal value). What you're saying, however, is that /reports?count=10 and /reports?count=20 are two different resources? This isn't what I understood at all, but it probably means I didn't understand it correctly. If that's the case, I apologise for wasting your time and will be doing some more reading on what a resource actually is. Regards, Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2380725
Re: JAX RS exceptions with illegal QueryParameter
Sorry, should read: The query string in a URI contribute to identify the resource, just like other path components (e.g. /reports). So yes, the /reports? count=10 and /reports?count=20 URIs identify two different resources (or things): the list of the first ten reports and the list of the first twenty reports. /reports is yet another resource: the list of all available reports. Best, Philippe Mougin Le 6 août 09 à 12:55, Philippe Mougin a écrit : The query string in a URI contribute to identify the resource, just like other path components (e.g. /reports). So yes, the /reports? count=10 and /reports?count=20 URIs are two different resources (or things): the list of the first ten reports and the list of the first twenty reports. /reports is yet another resource: the list of all available reports. Best, Philippe Mougin Le 6 août 09 à 09:53, Nicolas Rinaudo a écrit : From your answer, I think I might be misunderstanding the basic concept of a resource. The way I understand it is, if you have a /reports resource that lists all available reports and accepts a count parameter that limits the number of reports returned in a given query, /reports? count=10 and /reports?count=20 are the same resource. With that in mind, /reports?count=foobar isn't a 404 (the reports resource was found) but a 400 (query parameter 'count' has an illegal value). What you're saying, however, is that /reports?count=10 and /reports? count=20 are two different resources? This isn't what I understood at all, but it probably means I didn't understand it correctly. If that's the case, I apologise for wasting your time and will be doing some more reading on what a resource actually is. Regards, Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2380725 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2380781 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2380784
RE: Re: JAX RS exceptions with illegal QueryParameter
Understood, and after thinking about it, I do agree with your definition. On the other hand (and this is purely academic), I do find that returning 404 if a query parameter is malformed is not helpful to the client: it's not incorrect, since the resource wasn't found, but answering 400 tells him the reason why the resource couldn't be found - because the server couldn't understand his query and he should try and fix it. Both seem correct to me, and I find that 400 gives more information to clients. Bit of a moot point though, since there appears to not be any way for me to do that using JAX RS :) Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2380801
Re: JAX RS exceptions with illegal QueryParameter
Hi Nicolas, what's the difference for the user? You could add additional infos for both cases, but you have to implement it yourself. BTW: This reaction is defined in the JAX-RS spec (Version 1.1, https://jsr311.dev.java.net/drafts/spec20090313.pdf, page 8, last paragraph): A WebApplicationException thrown during construction of field or property values using 2 or 3 above is processed directly as described in section 3.3.4. Other exceptions thrown during construction of field or property values using 2 or 3 above are treated as client errors: if the field or property is annotated with @MatrixParam, @QueryParam or @PathParam then an implementation MUST generate a Web-ApplicationException that wraps the thrown exception with a not found response (404 status) and no entity; if the field or property is annotated with @HeaderParam or @CookieParam then an implementation MUST generate a WebApplicationException that wraps the thrown exception with a client error response (400 status) and no entity. The WebApplicationException MUST be then be processed as described in section 3.3.4. best regards Stephan Nicolas Rinaudo schrieb: Understood, and after thinking about it, I do agree with your definition. On the other hand (and this is purely academic), I do find that returning 404 if a query parameter is malformed is not helpful to the client: it's not incorrect, since the resource wasn't found, but answering 400 tells him the reason why the resource couldn't be found - because the server couldn't understand his query and he should try and fix it. Both seem correct to me, and I find that 400 gives more information to clients. Bit of a moot point though, since there appears to not be any way for me to do that using JAX RS :) Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2380983
RE: Re: JAX RS exceptions with illegal QueryParameter
Yes, you're absolutely right, that's in the JAX RS specifications. I was just wondering whether RESTlet had an extension to the basic specifications that allowed more control over what error code was used (an @Error(400) annotation, for example). The different for the user, if we're talking about a web user, is slim at best. An error occurred but that's not really his problem, the UI should have sheltered him from such basic syntax errors. For the developer writing a client application, however, it can save a lot of time. Knowing precisely why your implementation fails is always preferable in my opinion than just having a generic failed error. I'm oversimplifying things here, but that's the difference between throwing a NumberFormatException and a generic Exception. Apologies if I'm taking the debate too far, I'm aware that RESTlet is following the specifications to the letter and am not complaining about that at all. To be honest, I should have asked that question to the JAX RS design group but couldn't find any public forum and thought that since Jérome Louvel sits at that comity and is working on the implementation of the specifications that I'm using, this would be the next best place to voice my questions... Regards, Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2381083
Re: JAX RS exceptions with illegal QueryParameter
Hi Nicolas, On Aug 6, 2009, at 4:29 PM, Nicolas Rinaudo wrote: Yes, you're absolutely right, that's in the JAX RS specifications. I was just wondering whether RESTlet had an extension to the basic specifications that allowed more control over what error code was used (an @Error(400) annotation, for example). The different for the user, if we're talking about a web user, is slim at best. An error occurred but that's not really his problem, the UI should have sheltered him from such basic syntax errors. For the developer writing a client application, however, it can save a lot of time. Knowing precisely why your implementation fails is always preferable in my opinion than just having a generic failed error. FWIW, I agree with you here. In the situation you described in the original e-mail, I'd use either 400 or 422 with a message describing the problem. I don't use JAX-RS, though, so I can't help you on your technical question. Rhett I'm oversimplifying things here, but that's the difference between throwing a NumberFormatException and a generic Exception. Apologies if I'm taking the debate too far, I'm aware that RESTlet is following the specifications to the letter and am not complaining about that at all. To be honest, I should have asked that question to the JAX RS design group but couldn't find any public forum and thought that since Jérome Louvel sits at that comity and is working on the implementation of the specifications that I'm using, this would be the next best place to voice my questions... Regards, Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2381083 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2381095
RE: Re: JAX RS exceptions with illegal QueryParameter
I haven't tested it myself, but I'm not sure that ExceptionMappers actually kick-in for exceptions triggered by the underlying Engine. Regardless of that consideration though, the WebApplicationException thrown in such cases is just a generic one with a 404 status code. Even if I could write an ExceptionMapper to catch it, there'd be no way for me to differentiate it from other 404s. Well, let me rephrase that. I don't see how I'd go about differentiating it, but I'd love to hear your thoughts on the subject :) Regards, Nicola -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2381106
RE: Re: JAX RS exceptions with illegal QueryParameter
To be honest, I'm only using JAX RS on a side project to evaluate the technology. I'm loving it so far, once you get the hang of it it makes your code extremely clean and easy to maintain, provided you don't mind having more annotations than actual Java code. I sometimes feel a bit trapped by it though - like a lot of specifications, it makes a lot of decisions for you and I don't always agree with them. I haven't tested RESTlet 2.0 yet, but it sounds like a good mix of both, where the general case is handled well but you still get a chance to tweak things and do them your way when necessary. I guess that's probably the answer to my technical question :) Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2381109
