Mate... it may know something...which is not the same that knows what YOU actually want. Jersey can only start making assumptions from that point on... will they be valid and fit your needs? Hard to tell.
Query parameters should be banned. They are for REST the equivalent of Java script for the web.
Date: Sun, 17 Apr 2011 23:30:56 -0700
From: jason_at_jasonerickson.com
To: users_at_jersey.java.net
Subject: [Jersey] Re: How to catch the response in case of an invalid query paramter
Message body
But surely if you specify a method thus:
@GET
public Entity getById(@QueryParam(“id”) long id) {
...
}
It does know something about how to validate the call. It knows that if ?id=xyz is included, that’s not acceptable because id must be a long.
Contrary to what Ryan says, you can use a query parameter to choose between two resources. In fact, in a way, that’s always what you’re doing if the query parameter actually affects what gets returned. However, although query parameters are part of the URL, it is very strange in my opinion to call ?id=xyz on then end of that URL a 404 and not a 400 error. I understand it for @PathParam, but it seems to be a pretty uncommon way of thinking about query parameters.
Ryan,
It is what it is. You build an application with the JAX-RS implementation you have, not the one you wish you had. Have you thought about using an ExceptionMapper? It doesn’t sound like quite the fit you are looking for, but maybe it’s close enough to work.
On 4/17/11 9:18 PM, "Rob -" <skyscrapper666_at_hotmail.com> wrote:
I state again that Jersey does not know the semantics of your call. Assume you have a uri of the form:
GET /bookmarks/keywords/{ALL|10|50|100}
Passing in the "ALL" string would be valid. Passing the string "50" would be valid. Passing the Int 100 would be valid. Passing the string "xyz" would be invalid and should be considered as a bad request. How does Jersey know about what is valid or not? It can't.
Validating yourself your parameters may be stone age but works and places the logic on your side of things rather than the framework (where it should not be). Unless you wanna wait for an enhancement release and do it by the holy book of automation.
Date: Sun, 17 Apr 2011 20:52:01 -0500
From: rds6235_at_gmail.com
To: users_at_jersey.java.net
Subject: [Jersey] Re: How to catch the response in case of an invalid query paramter
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> 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
Date: Sun, 17 Apr 2011 17:07:45 +0200
To: 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
>
>