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