Can you provide more detail about the verb to SQL mapping?
I'm assuming something like:
delete /{catalog}/{schema}/{table}?column1=value
becomes "DELETE FROM catalog.schema.table WHERE column1=value"
Can you confirm and provide more detail on the handling of things like:
-update change sets
-null values (in both predicates and in insert/update changes)
-non-equality predicates
-output mapping (are we binding to xml and in what format, or json, etc.)
Also I'm assuming that this approach is only for new development. What about matching
the expected behavior of legacy restful services?
----- Original Message -----
We have been wrestling with the best way to implement a RESTFul
interface to a VDB. Here are the options we have come up with to date:
1. Create a hook to procedures to allow a mapping from HTTP verbs to
procedures in a model within a VDB. This war would be generated from
Designer and there would be one war per VDB.
Example... if I have a procedure name rgetBooks() the procedure would
map to a GET at URI=/books and would return all books (assuming that
the procedure was written correctly)
2. Create a single war that would have pre-defined URIs for table
access for any JDBC connection. Multiple connections could be
supported within the same war based on the URI. The JNDI names would
be entered by the user in a properties file or some analogous
mechanism.
Example URI=/{dbschema}/{catalog}/{table}?column1=value would return
the record corresponding to "value" in the target table
Procedures could also be supported in this manner.
3. Another option would be to generate the war discussed in option 2
from Designer to eliminate the need for the user to hand edit a
properties file.
There are pros and cons for all the options. 1 puts more onus on the
user but 2/3 are definitely the more complicated solutions and they
require intimate knowledge of the underlying metadata.
Please respond with your feedback on these proposed solutions and feel
free to add other alternatives.
Thanks,
Ted
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev