[teiid-dev] REST Interface to TEIID

[Steven Hawkins]

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