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

Tue May 3 13:20:12 EDT 2011

What is the legacy support for Restful service we are talking about? I
thought MMX not Teiid never exposed data through REST before. Am I
missing something here?

Second, trying to mimic and come up with our own htsql like
functionality is lot of work (it took them 6 years). We need to see if
we can re-use their framework or something similar framework and
integrate with Teiid. HTSQL have port for Postgres, unfortunately their
implementation is all Python based, we need to bridge the gaps to deploy
into JBoss. This would be very nice long term goal.

I agree with you that we are not going to implement query like semantics
the procedure approach is quick hitter, however I am opposed to the idea
of creating a new REST-model in the Designer for this (That is what I
understood is required). We should probably just work on enabling the
current Web service models through Rest, instead of SOAP interface. In
this scenario only issue really is how to covert the XML into JSON or
alike. This will take us to same expectations as with SOAP. May be this
what you are saying?

Ramesh..

On Tue, 2011-05-03 at 11:25 -0400, Steven Hawkins wrote:
> Just to be clear, what I am getting at is that I would rather see us focus in the near term on a narrowly scoped enablement of RESTFul services for EDS.  The more we attempt to invent or define a lot of new query semantics (like ht:sql) the more we are pushing out implementation and ensuring that the usage is only for new development.
> 
> ----- Original Message -----
> > ----- 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
> _______________________________________________
> teiid-dev mailing list
> teiid-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev