How to check REST invalid query parameter name with RESTEasy? - java

How to fail on invalid query parameter name with RESTEasy?
Consider a valid REST request like this one: /list?sort-by=date
Then, user makes this request: /list?sort_by=date
See that user replaced hyphen with underscore. It works, but it will ignore parameter and use default sorting (param not mandatory).
With Jackson, if a JSON with invalid member is sent it throws an Exception. I would like a similar behavior to query params (header params would be awesome too). Tested with #BeanParam, but apparently it doesn't use Jackson in this case.
RESTEasy version 3.15.1.

You have to check that in your code. Query params are not in json in standard, you can do that with a class with string constructor.
In fact "sort_by" is not bind to a method parameter, so it's ignored.
If you want that "sort-by" to be mandatory you have to do that in your code :
Required #QueryParam in JAX-RS (and what to do in their absence)
Currently since RESTEasy is built on top of a Servlet, it does not distinguish between URI query strings or url form encoded parameters. Like PathParam, your parameter type can be an String, primitive, or class that has a String constructor or static valueOf() method.
https://docs.jboss.org/resteasy/docs/3.15.1.Final/userguide/html_single/#_QueryParam

Related

How to keep nulls in a Spring GET servlet?

#RestController
public class MyController {
#GetMapping("/get)
public void get(Map<String, String> params) {
println(params.get("optional")); //"null"
}
#PostMapping("/post)
public void post(Map<String, String> params) {
println(params.get("optional")); //null
}
}
localhost:8080/get?key=value&optional=null
Result: the value of the key optional will be "null" written as String, not as null type.
Whereas a POST request would work as follows:
{
"key": "value",
"optional": null
}
Question: how can I make the GET request behave the same as POST? Means, how can I tell spring to interpret the null string in a GET as a real null?
You can't pass null via HTTP query parameter like you do it in JSON. Because null within an HTTP query has no special meaning and is treated like any other string.
Instead just don't pass optional parameter at all
localhost:8080/get?key=value
You could do something like this as well.
#RequestParam(name = "optional", required = false) String optional
Spring Docs
Like #Nikolai says, null has no special meaning in the query. The query is often called the Query String such as in AWS API Gateway, which is more descriptive that it tells you that it is a String, it isn't a Map, Strings only have chars encoded, there is no concept of a null in this context.
IMO it isn't good practice to use a Map<String,String> params if you can avoid it, rather prefer strong types and list all the possible query params with optional parameters for non-required inputs. If you want the users to specify a Map it should be in the BODY, but a GET with a body feels wrong to me so you might need to then change the HTTP method.
If you have many parameters, and that's why you are using a Map, remember some browsers limit the chars in a URL to 2048, so it can be dangerous and you may have a case whereby the user cannot specify all the parameters they need to because of this limit.
TL;DR: Map<String,String> should be in request body.

Deserializing List<Map<String, String>> QueryParam in jersey 1

I'm trying to implement a method in a dropwizard resource, that will service a call from a JS frontend (that uses DataTables).
The request has query parameters that look like this:
columns[0][data]=0&columns[0][name]=&columns[0][searchable]=false&columns[0][orderable]=false&columns[0][search][value]=&columns[0][search][regex]=false
columns[1][data]=iata&columns[1][name]=iata&columns[1][searchable]=true&columns[1][orderable]=true&columns[1][search][value]=&columns[1][search][regex]=false
The request comes from a JS frontend implemented with DataTables, and uses server-side processing. Info about how datatables sends the requests here:
https://datatables.net/manual/server-side
I'm having issues defining the data type for the above query parameters. With spring data, we can define it as:
List<Map<String, String>> columns
which can be wrapped in an object annotated with ModelAttribute and it will deserialize fine.
In my app I'm using an older version of dropwizard which depends on jersey 1.19.
I've tried annotating it as a QueryParam, but the app fails at startup.
Method:
#Path("/mappings")
#GET
#Timed
#Consumes(MediaType.APPLICATION_JSON)
#Produces(MediaType.APPLICATION_JSON)
public Response getMappings(#QueryParam("columns") List<Map<String, String>> columns) {
// processing here.
}
When I do this, I get:
ERROR [2016-11-07 14:16:13,061] com.sun.jersey.spi.inject.Errors: The
following errors and warnings have been detected with resource and/or
provider classes: SEVERE: Missing dependency for method public
javax.ws.rs.core.Response
com.ean.gds.proxy.ams.application.resource.gui.IataMappingGuiResource.getMappings(java.util.List)
at parameter at index 0 WARN [2016-11-07 14:16:13,070] /: unavailable
My question is: do I have any option other than writing a custom deserializer for it ?
Note: If I grab the request with #Context, I can see that the decodedQueryParams are a MultivaluedMap, which maps String keys like "columns[0][data]" to Lists of String values, which always have a single element, that is the value.
Update:
After some digging, I found the following JAX-RS specification (section 3.2) which explains why my approach isn't valid to begin with:
The following types are supported:
Primitive Types
Types that have a constructor that accepts a single String argument.
Types that have a static method named valueOf with a single String argument.
List, Set, or SortedSet where T satisfies 2 or 3 above.
Source: Handling Multiple Query Parameters in Jersey
So I've tried using just a List instead. This doesn't crash the app at startup, but when the request comes in, it deserializes into an empty list. So the question remains as to what approach is correct.
In fact, you're using such a very different structure from all the common ones we have mapped for Rest Web Services consummation. Also, because of this structural compliance problem, trying to use JSON to marshal/unmarshal the values won't suit, once we haven't object-based parameters being transported.
But, we have a couple of options to "work this situation around". Let's see:
Going with the #QueryParam strategy is not possible because of two main reasons:
As you noticed, there are some limitations on its use regarding Collections other than Lists, Sets, etc;
This annotation maps one (or a list) of param(s) by its(their) name(s), so you need every single parameter (separated by &) to have the same name. It's easier when we think about a form that submits (via GET) a list of checkboxes values: once they all have the same name property, they'll be sent in "name=value1&name=value2" format.
So, in order to get this requirement, you'd have to make something like:
#GET
public Response getMappings(#QueryParam("columns") List<String> columns) {
return Response.status(200).entity(columns).build();
}
// URL to be called (with same param names):
// /mappings?columns=columns[1][name]=0&columns=columns[0][searchable]=false
// Result: [columns[1][name]=0, columns[0][searchable]=false]
You can also try creating a Custom Java Type for Param Annotations, like you see here. That would avoid encoding problems, but in my tests it didn't work for the brackets issue. :(
You can use regex along with #Path annotation defining what is going to be accepted by a String parameter. Unfortunately, your URL would be composed by unvalid characteres (like the brackets []), which means your server is going to return a 500 error.
One alternative for this is if you "replace" this chars for valid ones (like underscore character, e.g.):
/mappings/columns_1_=0&columns_1__name_=
This way, the solution can be applied with no worries:
#GET
#Path("/{columns: .*}")
public Response getMappings(#PathParam("columns") String columns) {
return Response.status(200).entity(columns).build();
}
// Result: columns_1_=0&columns_1__name_=
A much better way to do this is through UriInfo object, as you may have tried. This is simpler because there's no need to change the URL and params. The object has a getQueryParameters() that returns a Map with the param values:
#GET
public Response getMappings(#Context UriInfo uriInfo) {
MultivaluedMap<String, String> queryParams = uriInfo.getQueryParameters();
// In case you want to get the whole generated string
String query = uriInfo.getRequestUri().getQuery();
String output = "QueryParams: " + queryParams
+ "<br> Keys: " + queryParams.keySet()
+ "<br> Values: " + queryParams.values()
+ "<br> Query: " + query;
return Response.status(200).entity(output).build();
}
// URL: /mappings?columns[1][name]=0&columns[0][searchable]=false
/* Result:
* QueryParams: {columns[0][searchable]=[false], columns[1][name]=[0]}
* Keys: [columns[0][searchable], columns[1][name]]
* Values: [[false], [0]]
* Query: columns[1][name]=0&columns[0][searchable]=false
*/
However, you must be aware that if you follow this approach (using a Map) you can't have duplicated keys, once the structure doesn't support it. That's why I include the getQuery() option where you get the whole string.
A last possibility is creating a InjectableProvider, but I can't see many diffs to the getQuery() strategy (since you can split it and create your own map of values).

API Gateway: "Can not deserialize instance of java.lang.String out of START_OBJECT token"

There are other questions covering this error, but they are looking for accessing query parameters, which is not my scenario.
Testing my simple GET request fails with the following in the errorMessage field in the test console:
Can not deserialize instance of java.lang.String out of START_OBJECT token\n at [Source: lambdainternal.util.NativeMemoryAsInputStream#6bdf28bb; line: 1, column: 1
My lambda function is a simple Java class with a static method get that takes one parameter: an id from a path param.
For example, doing a GET to mysite.com/resource/1 should pass 1 to the get method of my static class.
I haven't set up a mapping for this because I'm not mapping the request body. The API Gateway documentation is very confusing and also quite light on its example covering a similar scenario.
How can I map a path parameter to my lambda function's parameter?
Just for background, the Lambda functions don't have any concept of "parameters"; everything has to go into the request payload to the function. So in your case you need to use a mapping template on the Integration to transform the incoming GET parameters into a JSON payload that you can give to Lambda.
The path parameters are available in the same mapping template object as query string parameters, which is $input.params([name]) where [name] is the name of the parameter.
So your template would look like this:
Content-Type: application/json
Template:
{
"resourceId" : "$input.params('your_name_here')"
}
I put the JSON value in quotes but if the value is guaranteed to be a number you could remove them. Probably safer to put it in quotes anyway.
Here's the template reference: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html
The Content-Type is actually important here because API Gateway will checks the Content-Type header of the incoming request to determine which mapping template to use. Usually in GET requests there is no Content-Type header, so API Gateway assumes that you want 'application/json' so if your template is mapped to a content type other than application/json, it won't work as expected.
Edit: more background on Lambda integration

List of possible overloads for Jersey JAX-RS resources

I'm using Jersey to implement a JAX-RS resource. I've seen lots of different examples on Stack Overflow, various blogs and the Jersey User Guide.
I would like to know what the different overloads can be for a given resource handler. Is there a single source where these are documented?
For example, the following handles an HTTP POST request. The request body is captured as a MultivaluedMap.
#POST
public Response httpPostRequest(MultivaluedMap<String, String> body)
{
...
}
Alternatively, the following overload captures the body as a single String.
#POST
public Response httpPostRequest(String body)
{
...
}
There are other overloads too. How many are there and where are they documented?
It is just a normal Java method that has one or more annotations associated with it. The signature of the method has no particular constraints placed on it by Jersey.
Having said that, you will want to make sure that the various annotations (e.g., #Produces, #Consumes, #PathParam, #QueryParam) are applied to data types that Jersey knows how to map. For example, Jersey has no problem with mapping #PathParam to String or long. Jersey can also work with Java classes that have JAXB annotations, so your method signature can include a JAXB type combined with #Consumes(MediaType.APPLICATION_XML) and Jersey will convert the request content from an XML document to the JAXB Java class.
For example:
#GET
#Produces(MediaType.APPLICATION_XML)
#Path("somepath")
public Foos getFoosByQuery(#PathParam("businessName") String businessName,
#PathParam("businessUnitName") String businessUnitName, #PathParam("fileType") String fileType,
#QueryParam("from") String fromString, #QueryParam("to") String toString,
#DefaultValue("10") #QueryParam("interval") int intervalMinutes,
#DefaultValue("1000") #QueryParam("limit") int limit,
#DefaultValue("false") #QueryParam("errors") boolean errors) {
Here, we see that we have many parameters (with types String, int and boolean) and a return type that is a JAXB-annotated POJO. Jersey pulls the #PathParam values from the path, the #QueryParam values from the query string and converts the return value into an XML document and includes it as the content of the response.
I will also note that the name of the method can be anything we want, so the concept of "overloading" is orthogonal to Jersey. The normal Java overloading rules apply.
It should be obvious from this example that you cannot enumerate all of the possible "overloads" that you can use with Jersey.
Perhaps a different question regarding all of the possible type mappings that Jersey can do would be more in line with what you are looking for.

Arbitrary name for RESTEasy QueryParam?

Is there a way to get any query parameter without explicitly declaring its name using the #QueryParam annotation?
I have a string which may have tokens like {animal}, which are then replaced by the query parameter posted, e.g. ?animal=fox, but I want the name of the token to be configurable as well. Ideally I would like to be able to do something like this:
for (QueryParam param : queryParams) {
text = text.replaceAll("{" + param.key + "}", param.value);
}
(I'm guessing you are talking about writing a resource to accept a query string correct?)
In which case, in your method, you can use #Context to get a UriInfo object which you an use to obtain a MultivaluedMap of all of your query string parameters.

Categories

Resources