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=4447&dsMessageId=2380983
