Re: [teiid-dev] REST Interface to TEIID

----- Original Message ----- > Steve, > > Yes... delete /{catalog}/{schema}/{table}?column1=value becomes > "DELETE FROM catalog.schema.table WHERE column1=value" > > Also, by allowing procedures to be exposed RESTFully as well, we can > handle more complex processing. > > With regards to: > > -update change sets: Are you asking how will updates be handled? I > am > thinking for the input we will expect JSON only and build our SQL > accordingly. Not sure if that's what you meant though. :-) The question is how will the change set be sent. Your indicating as JSON, i.e. {column1:value}. Does that also imply only literal values, or would you also support expressions? > -null values: We can candle null values via the JSON provider Can you provide an example for a GET predicate?

> (RESTEasy support Jackson). > -non-equality predicates: This could be handled in a procedure > -output mapping: We would support JSON only > > By legacy restful services, do you mean our current rest support? I > don't see that changing. No I mean what we seem to be doing here is a very open ended design of a completely new project (see also Ramesh's suggestion of ht:sql or the servlet based project that you were referencing). That is well and good for new development, but the primary use case for EII/virtualization is providing the ability to easily match existing interfaces. If someone already has a RESTful dataservice defined and wants to have EDS handle it, what is the recommended approach? > > ----- Original Message ----- > From: "Steven Hawkins" <shawkins(a)redhat.com&gt; > To: "Ted Jones" <tejones(a)redhat.com&gt; > Cc: "Randall Hauch" <rhauch(a)redhat.com&gt;, "teiid-dev" > <teiid-dev(a)lists.jboss.org&gt;, "teiid-designer-dev" > <teiid-designer-dev(a)lists.jboss.org&gt; > Sent: Monday, May 2, 2011 4:18:13 PM > Subject: Re: [teiid-dev] REST Interface to TEIID > > 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