Getting 404 For Wrong Parameter Type

[Saad Mufti]

Hi,

I have an API done using the latest 0.7.0-SNAPSHOT (recently migrated) and recently noticed an issue (not sure whether it was there when the code was on 0.6.2). I have a resource method with the following declaration:

    @GET

.

.

.

     public Optional<List<ScoredPromotion>> selectPromotions(@PathParam("client_id") String client_id,

                                                                        @PathParam("coll_id") String coll_id, 

                                                                        @QueryParam("num_slots") Integer num_slots,

                                                                        @QueryParam("uid") String uid)

When I try 

http://localhost:8080/v1/selection/aol/aol_PA?num_slots=10

it works fine. When I try

http://localhost:8080/v1/selection/aol/aol_PA?num_slots=badparam

I get a 404 Not found.

Is this the right status? I would've expected something like 400 Bad Request or something.

Anyone have any insight?

Thanks.

----

Saad

[Saad Mufti]

Oh just read Jersey 1.17 documentation at https://jersey.java.net/documentation/1.17/jax-rs.html#d4e254 and apparently this is by design, any parameter that cannot be successfully parsed as the given type will return a 404 . But still trying to wrap my head around the reson, why not give the caller a more actionable error like 400 parameter could not be passed as Integer or something? Anyone know?

Thanks.

----

Saad

[Ted M. Young [@jitterted]]

Probably a better question for the Jersey mailing list. Also, this is why I use String for all of my parameters so that I can do better error checking/handling/reporting.

;ted

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Saad Mufti]

True it is really a Jersey question but I figured there should be lots of Jersey experts here. In any case, a better approach than declaring all your parameters as String and doing error checking in your resource method is to give them a custom type and move the error checking into that class. For example take a look at the package io.dropwizard.jersey.params and the various parameter classes in there. I chose to use IntParam from that package instead of plain Integer as I was using when I posted this question. For a couple of other application specific parameter types I wrote my own parameter classes instead of sub-classing io.dropwizard.jersey.params.AbstractParam<T> but that was just because at the time I wrote them I wasn't aware of that class.

Cheers.

----

Saad

[Ted M. Young [@jitterted]]

You're right, I had totally forgotten about the Param classes (Coda describes them here: http://codahale.com/what-makes-jersey-interesting-parameter-classes/). Thanks for the reminder.

;ted

[Saad Mufti]

Even with this, in my opinion, better approach, there is one shortcoming. Since the parameter name is never passed to the custom parameter class, the error report cannot tell the caller which parameter failed to parse, it can only report on the value which failed to parse. In most cases it won't matter and the faulty parameter will be obvious, but it would be nicer to report something like "parameter num_slots expected to be integer, value 'all' is not an integer". With your approach of treating everything like a String you can report these kinds of error messages. Still I think the advantages in less repetitive code make the custom parameter class approach worth it.

----

Saad