I am trying to find the best way of getting round a design flaw in a web app I'm helping to support. One part of the service passes a parameter ("myparam") to a .jsp page, which in turn calls a REST service including our myparam as a path parameter. The design flaw bit is that myparam should be passed as a form parameter, since it can be free text. However, we cannot change the implementation as other parties are involved at the .jsp end of things.
My solution was to encode the myparam using hex encoding (url encoding alone doesn't work as you end up with "%" etc. which the org.restlet implementation of REST doesn't like seeing in path parameters). Using the Apache codec library, I have something like this:
Option 1 (just hex):
String decodedParam = new String(Hex.decodeHex(myparam.toCharArray()));
which works for our purposes. What I really wanted to do was to combine URL- and Hex-encoding, so that I can really cover all posibilities:
Option 2 (hex + url-decoding):
Parameter preparation:
String workText = URLEncoder.encode(inText, encoding); // a
char[] encodedBytes = Hex.encodeHex(workText.getBytes()); // b
String myparam = new String(encodedBytes);
Decoding (REST):
String decodedParam = new String(Hex.decodeHex(myparam.toCharArray())); // c
String doubleDecodedParam = URLDecoder.decode(decodedParam, "UTF-8"); // d
I have two questions:
why doesn't the second option work? (whenever I try and URL-decode my string at d) I get a java.lang.IllegalArgumentException). I've tested the double-encoding-and-decoding of my parameter values at http://ostermiller.org/calc/encode.html without problem.
is there a better way to encode path parameters with REST?