REST:URI accepting null parameter?

[gioppoluca]

I've defined a virtual procedure to be exposed as a REST API, but I'd like to have a REST:URI like this one:

mypath/{id}

where {id} can be null and I can have in the procedure a IF cluse that either get the select * from table or in the other case build the WHERE clause.

Do I have to create two procedures?

One for the "mypath/"

the other for the "mypath/{id}"

Since the id input parameter is nullable I expected that it could accept a null

[tejones]

Hi Luca,

By "null" do you mean not present or the word "null"? I know this wouldn't work if no value is present, since the expected parameters are matched up in the method. Can you try passing the word "null" and check for that value in your procedure? I know it is a bit of a hack, but feel free to log a Jira to handle optional parameters in the REST war if this doesn't work or is not acceptable. We can do something with regular expressions as outlined here: http://www.nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-parameters/

Thanks,

Ted

[shawkins]

The OData procedure invocation was updated to handle missing parameters, but here the parameter handling is a little bit more out of our control so I don't know how easy it would be (the jax-rs link above looks messy). 

> Can you try passing the word "null" and check for that value in your procedure?

That will pass a string literal null, so any non-string type will cause a failure (or you'd have to create a wrapping procedure accepting a string).

Steve

[gioppoluca]

The goal is to present an API that tipically answer to:

/myobiects  (get the list of myobjects)

/myobjects/{id} (get just the single object with id of some value)

Obviously I have 2 different query here

one is a

select * from myobjectstable

the other is

select * from myobjectstable where col_id=id

To be lazy all could be done in a single virtual procedure if the system could be so clever to understand a null value (NOT the "null" string ) of an input parameter.

This should be reasonable since the input parameter of a virtual procedure can be nullable and should be possible to check for null values.

Not being lazy I believe that an option is to have 2 procedures one that get called for one path the other for the second but ...

It seems that the {choose_your_parameter_name} of a REST:URI cannot be null and this could be a problem since many times API can have optional parameters that have default values.

Let me know if you need an issue for this

[shawkins]

Perhaps OData would be a good choice here.  It already understands filter strings and other query functionality as part of the spec.

http://www.odata.org/documentation/odata-v2-documentation/uri-conventions/#45_Filter_System_Query_Option_filter

[gioppoluca]

not if I want to have a more complex query and if I'd like to have more than one parameter.

I think that OData cannot be the only way out.

We need to be able to get API in our way and we need to be able to correctly map the REST:URI with the procedure parameters

Than at the time OData does not work perfectly enough (this is blocking us [TEIID-2656] Teiid OData Servlet throws java.lang.NullPointerException on every GET - JBoss Issue Tracker) so OData still not an option.

[shawkins]

> not if I want to have a more complex query and if I'd like to have more than one parameter.

Is that in reference to OData?

> We need to be able to get API in our way and we need to be able to correctly map the REST:URI with the procedure parameters

I don't disagree, I'm just suggesting OData since what you are doing:

a. calling procedures with defaultable parameters

b. mapping the uri to a query

Are both supported by the OData layer.

> Than at the time OData does not work perfectly enough

I replied to your comment on the issue.

If you have tried something like http://stackoverflow.com/questions/5421104/optional-pathparam-in-jax-rs for the uri pattern it may work, but the current back end will explicitly bind a null value such that a default will not be used.  However I haven't tried this so I don't know if you'll hit any other snags.  So at least an issue is needed to handle defaultable parameters better.

[gioppoluca]

I admit that I have not looked deeply at OData and I still not understood if I can have a JSON exit and not a ATOM one.

The ATOM is not so nice for my purposes.

Will look at it and make some experiments.

Thanks

[rareddy]

see odata example here http://msdn.microsoft.com/en-us/library/ff478141.aspx

to get JSON, you can $format=json or add HTTP Header "accepts=application/json"

[gioppoluca]

Thanks !!!!

I did not had the time to study OData, but it is worth the time.

I think that Steven was right in suggesting the OData usage for my case.

I tryed the EAP+TEIID8.5 and ... it is well worth stepping into it.

So now we'll have to start a migration path to EAP6.1 alpha (lots of puppet scripts to change)

Thanks again

[shawkins]

Also logged [TEIID-2710] Rest procedures should support optional parameters - JBoss Issue Tracker to capture the original issue.