RESTFul URI parameter limitations/bugs
TobiasEMay 2 2013 — edited May 20 2014Hi,
I've run into some limitations (or bugs, don't know which is the most appropriate term at this point) regarding URI template parameters for RESTful Services. Here are a few examples to illustrate:
First limitation:
To start with, I define the following Resource Template: *example?p1={p1}&p2={p2}*
I use the following query as the GET handler: select :p1, :p2 from dual
This works fine, the URL example?p1=foo&p2=bar gets a json response like this: {":1": "foo",":2": "bar"}
I then create a second Resource Template with only the first parameter from the previous template: *example?p1={p1}*
I use the following query as the GET handler: select :p1 from dual
This works as expected, however now the previous template returns the following: {":1": "foo&p2=bar"}, i.e. the part of the URI string after p1= gets parsed as a single parameter.
Second limitation:
I define the following resource template: *example1/{p1}*
I use the following query as the GET handler: select :p1 from dual
Works fine.
I then define the following resource template: *example1/{p1}/example2*
I use the same query again as the GET handler: select :p1 from dual. This time the whole part of the URI string from {p1} forward gets parsed as the p1 parameter, which means it returns {":1":"foo/example2"} rather than {":1":"foo"}. However, if I remove the example1/{p1} template, the example1/{p1}/example2 works as expected.
In both cases, it seems like the rules for URI templates are excessively strict regarding URI similarities with other templates. I've been unable to find any reference to this in the documentation, other than a vague reference to a lack of support for "optional parameters".
Assuming these are known limitations rather than bugs, might they be removed in a future release?
Versions:
APEX Listener 2.0.1
WLS 10.3.6 on Windows 2008 R2 (64-bit)
Oracle DB 11.2.0.3
APEX 4.2.1
Thanks,
Tobias