On Dec 24, 2010, at 1:40 AM, java.net_at_jasonerickson.com wrote:
> I have a service defined thus:
> @GET
> public Observation[] getObservations(
> @QueryParam("startDate") Date startDate,
> @QueryParam("endDate") Date endDate,
> @QueryParam("observerId") Long observerId,
> @QueryParam("observerName") String
> observerName,
> @QueryParam("subjectId") Long subjectId,
> @QueryParam("subjectName") String subjectName,
> @QueryParam("phenomenonId") Long phenomenonId,
> @QueryParam("page") @DefaultValue("0") int
> page,
> @QueryParam("pageSize") @DefaultValue("25") int
> pageSize,
> @QueryParam("excludeLocationless")
> @DefaultValue("false") boolean excludeLocationless) {
> ... do some stuff
> }
>
> A client was passing 27.0 for observerId and was getting a 404 error.
> Naturally, he assumed that either the path to resource was invalid or
> that 404 meant that there were no results. But the problem was that
> 27.0 was not a Long. If he passed observerId=27, he did get results.
>
> My question is: Does this make sense? Wouldn't a 400 be more
> appropriate? Is this because of the JSR?
Yes, because query parameters are part of the URI. The EG went back
and forth on this one. I can see it both ways.
You can override the behavior with an exception mapper that maps:
http://jersey.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/ParamException.QueryParamException.html
In general we need improved validation of request information and
improved error reporting when invalidation occurs.
Paul.
> Or should I log it as a bug?