[teiid-dev] REST Interface to TEIID

[Steven Hawkins]

----- 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 at redhat.com>
> To: "Ted Jones" <tejones at redhat.com>
> Cc: "Randall Hauch" <rhauch at redhat.com>, "teiid-dev"
> <teiid-dev at lists.jboss.org>, "teiid-designer-dev"
> <teiid-designer-dev at lists.jboss.org>
> 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-dev