[teiid-designer-dev] [teiid-dev] REST Interface to TEIID

Steven Hawkins shawkins at redhat.com
Mon May 2 17:18:13 EDT 2011


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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev


More information about the teiid-designer-dev mailing list