users@jersey.java.net

[Jersey] Re: How to catch the response in case of an invalid query paramter

From: Jakub Podlesak <jakub.podlesak_at_oracle.com>
Date: Wed, 01 Jun 2011 18:25:33 +0200

Hi,

404 status here is aligned with the JAX-RS specification. See section
3.3.2 (resource method parameters),
which refers to 3.2 (page 10):

"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;"

I.e. Jersey just sticks with JSR-311 when returning 404.

~Jakub



On 04/18/2011 03:52 AM, Ryan Stewart wrote:
> On the contrary, it could be much easier. Jersey can certainly tell
> that the expected parameter type is an int and the provided value
> doesn't match. I'm a little surprised it doesn't return a 400 itself
> in this case. For one thing, a query parameter can't be used to pick
> between two resources. That's what the URI is for. For another, I
> believe Jersey does return a 400 if the entity can't be unmarshaled,
> doesn't it? It seems a little inconsistent. Whatever the case, asking
> a developer to pass in a String and parse it manually is pretty
> stone-age when it comes to web frameworks. I'm afraid I don't know if
> there's an answer to this in Jersey, but I've wondered about it
> myself, as it's somewhat annoying, though not enough so that I've done
> anything about it. I don't even know what kind of mechanism Jersey
> uses for the type conversions. Anybody? If we get some eyes on it,
> maybe a solution will be forthcoming.
>
> On Sun, Apr 17, 2011 at 8:21 PM, Rob - <skyscrapper666_at_hotmail.com
> <mailto:skyscrapper666_at_hotmail.com>> wrote:
>
> You don't have to catch anything.
>
> Just validate the parameters you want if they give error then send
> 400. It couldn't be much easier than that. Jersey cannot do it for
> you because it does not know the semantics of your call.
>
>
> ------------------------------------------------------------------------
> From: pengfei.di_at_match2blue.com <mailto:pengfei.di_at_match2blue.com>
> Date: Sun, 17 Apr 2011 17:07:45 +0200
>
> To: users_at_jersey.java.net <mailto:users_at_jersey.java.net>
> Subject: [Jersey] Re: How to catch the response in case of an
> invalid query paramter
>
> Yes, I also think status 400 is the correct one. The problem is
> that I cannot catch the response and set its status to from 404 to
> 400. Suppose the expected query parameter is int, and received is
> a string.
>
> Pengfei
>
> Am 17.04.2011 um 15:59 schrieb Rob - <skyscrapper666_at_hotmail.com>:
>
> Too convoluted and not practical.
>
> If you are sending in a STRING when you're expecting an INT
> then by definition you have a BAD REQUEST.
>
> A BAD REQUEST is a client problem, not a server side
> one. Therefore, you should just return status code 400 - Bad
> Request.
>
> Otherwise, you'll be violating well known practices.
>
> ------------------------------------------------------------------------
> Date: Fri, 15 Apr 2011 17:42:40 +0200
> From: daniel.j.larsson_at_gmail.com
> To: users_at_jersey.java.net
> Subject: [Jersey] Re: How to catch the response in case of an
> invalid query paramter
>
> I'm not sure what control you'll have of the response, but you
> can try create a wrapper class for the parameter:
>
> class IntParam {
> ...
> public static IntParam valueOf(String value) {
> // Parse string, try throw a WebApplicationException
> // with the response in case it fails. If I
> // remember correctly, the response here is
> // ignored though :/
> ...
> }
> }
>
> @GET
> @Path("get")
> public MyClass getSomething ( @QueryParam("age") IntParam age) {
> ...
> }
>
> 2011/4/15 Pengfei Di <pengfei.di_at_match2blue.com>
>
> thanks for the suggestions!
>
> Yes, I know that I can circumvent the problem by declaring
> the age as String.
> However, I really want to know whether it is possible to
> declare the age as Integer, and then catch the exception
> or define the response by myself.
>
>
> Pengfei
>
>
> On 04/15/2011 05:35 AM, Rob - wrote:
>
> yep, 400 Bad request is better.
>
> ------------------------------------------------------------------------
> Date: Fri, 15 Apr 2011 04:12:53 +0200
> From: daniel.j.larsson_at_gmail.com
> To: users_at_jersey.java.net
> Subject: [Jersey] Re: How to catch the response in
> case of an invalid query paramter
>
> Or 400 BAD REQUEST, the problem is with the client,
> not the server.
>
> 2011/4/15 Rob - <skyscrapper666_at_hotmail.com>
>
> I'd declare "age" as a string and handle the
> validation myself. If error then return a 500
> status code.
>
> No real benefits having "age" declared as integer
> (to my eyes).
>
> > Date: Thu, 14 Apr 2011 12:42:57 +0200
> > From: pengfei.di_at_match2blue.com
> > To: users_at_jersey.java.net
> > Subject: [Jersey] How to catch the response in
> case of an invalid query paramter
>
> >
> > Hello,
> >
> > I have a very simple GET REST API, which returns
> something only based on
> > the query parameter. For example:
> > @GET
> > @Path("get")
> > public MyClass getSomething ( @QueryParam("age")
> Integer age);
> >
> > As listed above, I specify the parameter type as
> Integer. However,
> > problem occurs when the given parameter cannot
> be parse to an integer.
> > For an instance: if the parameter is set as
> "age=one" instead of
> > "age=1", Jersey server will say "HTTP status 404
> - Not Found."
> >
> > What I want to do is to specify the response by
> myself, but I have no
> > idea where I can do it. Shouldn't Jersey throw an
> > NumberFormatException. In fact, it doesn't. :(
> >
> > Thanks for any hint
> > Pengfei
> >
> >
>
>
>
>
> --
> Pengfei Di
> Technology
>
> match2blue software development GmbH
> Leutragraben 1
> 07743 Jena
>
> Tel:+49 3641 816 8092 <tel:%2B49%203641%20816%208092>
> Mobil:+49 1520 166 8691 <tel:%2B49%201520%20166%208691>
> Fax:+49 3641 573 3479 <tel:%2B49%203641%20573%203479>
> Email:pengfei.di_at_match2blue.com
> Web :www.match2blue.com
> Blog :http://blog.match2blue.com
> Registergericht: Amtsgericht Jena
> Registernummer: HRB 503726
> Geschäftsführerin: Stephanie Renda
>
>
>
>
>