9:10 p.m.
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
11:18 p.m.
New subject: [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
3:51 p.m.
New subject: [teiid-dev] REST Interface to TEIID
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. :-)
-null values: We can candle null values via the JSON provider (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.
----- 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
5:10 p.m.
New subject: [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>
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
5:25 p.m.
New subject: [teiid-dev] REST Interface to TEIID
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
6:50 p.m.
New subject: [teiid-dev] REST Interface to TEIID
Point taken Steve... so that is why you favor the first option.
For existing REST services that the user wants to expose, they will still be able to use
the WS Translator. What we are trying to do is expose data for a TEIID vdb in a RESTFul
manner. So the WS Translator consumes REST and options 1-3 below expose a TEIID source
RESTFully. I don't see legacy REST support being affected.
I am fine with going with option 1 and then perhaps morphing that into option 2/3 if
that's the consensus.
----- 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: Tuesday, May 3, 2011 10:25:42 AM
Subject: Re: [teiid-dev] REST Interface to TEIID
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
7:20 p.m.
New subject: [teiid-dev] REST Interface to TEIID
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(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
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
7:41 p.m.
New subject: [teiid-dev] REST Interface to TEIID
----- Original Message -----
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?
By legacy I mean someone has an existing RESTful service not implemented through EDS, but
wants to do it through EDS - the common virtualization use case.
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.
Sure, a long term goal would be to provide some general restful interface to relational
that can include all sorts of novel querying capabilities. Whether someone else has a
license friendly way of doing that or we develop it ourselves is an open question. My
concern however is still around the next EDS feature release. There are all sorts of
things we could do, but we have a rather short window to hit that release.
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).
No I am not in favor of introducing a rest meta-model. I would either be in favor of
starting off with just the assumed URI /{catalog}/{schema}/{procedure} mapping (it would
still be open what the data binding would be), or using the pending generic extension
metadata feature to set properties (similar to resteasy annotations) on the
procedure/params/results as to what their restful mapping should be.
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?
Since the web services model at it's core is just a set of procedures the only
difference with any other procedure is that the output is known to be xml.
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(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
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
12:56 a.m.
New subject: [teiid-dev] REST Interface to TEIID
For quick win, I would take current Web service model, and expose them
as REST. Since these procedures already expose XML, that should be it.
Exposing as JSON data should be done through some XML JSON converter
based on some URL flag. I would even consider adding this on to the
existing SOAP WAR generation stuff as an addon. I do not see any need
for us to use any REST frameworks for this either. Just come up with
simple schema included REST like URL and intercept and convert to same
execution object the SOAP stuff is doing.
Going after generic model with extension metadata not valuable at this
point IMO. Once we put the data binding on it, someone will say they
want it based on schema then goes back to the web service model anyway.
Ramesh..
On Tue, 2011-05-03 at 13:41 -0400, Steven Hawkins wrote:
----- Original Message -----
> 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?
>
By legacy I mean someone has an existing RESTful service not implemented through EDS, but
wants to do it through EDS - the common virtualization use case.
> 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.
>
Sure, a long term goal would be to provide some general restful interface to relational
that can include all sorts of novel querying capabilities. Whether someone else has a
license friendly way of doing that or we develop it ourselves is an open question. My
concern however is still around the next EDS feature release. There are all sorts of
things we could do, but we have a rather short window to hit that release.
> 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).
No I am not in favor of introducing a rest meta-model. I would either be in favor of
starting off with just the assumed URI /{catalog}/{schema}/{procedure} mapping (it would
still be open what the data binding would be), or using the pending generic extension
metadata feature to set properties (similar to resteasy annotations) on the
procedure/params/results as to what their restful mapping should be.
> 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?
Since the web services model at it's core is just a set of procedures the only
difference with any other procedure is that the output is known to be xml.
>
>
> 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(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
> > _______________________________________________
> > teiid-dev mailing list
> > teiid-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-dev
3:46 a.m.
New subject: [teiid-dev] REST Interface to TEIID
I think we may be going at this the wrong way. What I'm mostly interested in is what
we're doing for 7.4. I had been given the impression by Ted that he had some basic
mechanics in place for rest enablement of procedures, but I'm a little short on
details. My suggestions were built upon that assumption. So my question for Ted is, what
has been done and what in his estimation is doable in a short time frame out of the
options discussed thus far.
----- Original Message -----
For quick win, I would take current Web service model, and expose
them
as REST. Since these procedures already expose XML, that should be it.
What you are suggesting here would primarily remove soap enveloping.
Exposing as JSON data should be done through some XML JSON converter
based on some URL flag.
Given an existing mapping approach, such as our jsonToXml function (which is based upon
the logic from json.org) that conversion is straight-forward. The webservices model
however does not really buy you anything here other than ensuring that the procedure
results are xml (there is a little bit of messiness though in that web service operation
procedures return result sets that could in theory return multiple documents). Any
procedure that returns xml is just as valid of a starting point - and doesn't have to
drag in any notion of xml document models.
I would even consider adding this on to the
existing SOAP WAR generation stuff as an addon.
Maybe Ted can comment on how what he has will be generated/delivered.
I do not see any need
for us to use any REST frameworks for this either. Just come up with
simple schema included REST like URL and intercept and convert to same
execution object the SOAP stuff is doing.
Going after generic model with extension metadata not valuable at this
point IMO. Once we put the data binding on it, someone will say they
want it based on schema then goes back to the web service model
anyway.
Lets be clear on separating our concerns. As I see it there is primarily:
-rest protocol behavior - verb/uri/query string binding to sql
-a data binding for results/parameters/payload
To sum up. We just need to be aware that if we dictate the terms of the protocol
behavior, then we're asking people to target new development against our rest
solution. While I'm not saying that we can't do something novel in this regard, I
just having a hard time separating out what's being proposed in the near term. I also
want to make sure that we're not reusing web services models for the wrong reason.
As for data binding, I similarly don't want us dependent upon xml document models.
There are plenty of other ways of generating xml through Teiid (sql/xml, xquery, direct
from sources, etc.). We can also add a general purpose inverse to jsonToXml regardless of
the rest efforts.
Ramesh..
On Tue, 2011-05-03 at 13:41 -0400, Steven Hawkins wrote:
> ----- Original Message -----
> > 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?
> >
>
> By legacy I mean someone has an existing RESTful service not
> implemented through EDS, but wants to do it through EDS - the common
> virtualization use case.
>
> > 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.
> >
>
> Sure, a long term goal would be to provide some general restful
> interface to relational that can include all sorts of novel querying
> capabilities. Whether someone else has a license friendly way of
> doing that or we develop it ourselves is an open question. My
> concern however is still around the next EDS feature release. There
> are all sorts of things we could do, but we have a rather short
> window to hit that release.
>
> > 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).
>
> No I am not in favor of introducing a rest meta-model. I would
> either be in favor of starting off with just the assumed URI
> /{catalog}/{schema}/{procedure} mapping (it would still be open what
> the data binding would be), or using the pending generic extension
> metadata feature to set properties (similar to resteasy annotations)
> on the procedure/params/results as to what their restful mapping
> should be.
>
> > 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?
>
> Since the web services model at it's core is just a set of
> procedures the only difference with any other procedure is that the
> output is known to be xml.
>
> >
> >
> > 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(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
> > > _______________________________________________
> > > teiid-dev mailing list
> > > teiid-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/teiid-dev
3:07 p.m.
New subject: [teiid-dev] REST Interface to TEIID
What I have prototyped is a REST war using RESTEasy that exposes procedures for a Teiid
relational view. It consumes and produces XML. If we want to go with that I just need the
GUI component in place to generate the war. I should be able to have that for 7.4.
----- Original Message -----
From: "Steven Hawkins" <shawkins(a)redhat.com>
To: rareddy(a)redhat.com
Cc: "Ted Jones" <tejones(a)redhat.com>, "teiid-designer-dev"
<teiid-designer-dev(a)lists.jboss.org>, "teiid-dev"
<teiid-dev(a)lists.jboss.org>, "Randall Hauch" <rhauch(a)redhat.com>
Sent: Tuesday, May 3, 2011 8:46:44 PM
Subject: Re: [teiid-dev] REST Interface to TEIID
I think we may be going at this the wrong way. What I'm mostly interested in is what
we're doing for 7.4. I had been given the impression by Ted that he had some basic
mechanics in place for rest enablement of procedures, but I'm a little short on
details. My suggestions were built upon that assumption. So my question for Ted is, what
has been done and what in his estimation is doable in a short time frame out of the
options discussed thus far.
----- Original Message -----
For quick win, I would take current Web service model, and expose
them
as REST. Since these procedures already expose XML, that should be it.
What you are suggesting here would primarily remove soap enveloping.
Exposing as JSON data should be done through some XML JSON converter
based on some URL flag.
Given an existing mapping approach, such as our jsonToXml function (which is based upon
the logic from json.org) that conversion is straight-forward. The webservices model
however does not really buy you anything here other than ensuring that the procedure
results are xml (there is a little bit of messiness though in that web service operation
procedures return result sets that could in theory return multiple documents). Any
procedure that returns xml is just as valid of a starting point - and doesn't have to
drag in any notion of xml document models.
I would even consider adding this on to the
existing SOAP WAR generation stuff as an addon.
Maybe Ted can comment on how what he has will be generated/delivered.
I do not see any need
for us to use any REST frameworks for this either. Just come up with
simple schema included REST like URL and intercept and convert to same
execution object the SOAP stuff is doing.
Going after generic model with extension metadata not valuable at this
point IMO. Once we put the data binding on it, someone will say they
want it based on schema then goes back to the web service model
anyway.
Lets be clear on separating our concerns. As I see it there is primarily:
-rest protocol behavior - verb/uri/query string binding to sql
-a data binding for results/parameters/payload
To sum up. We just need to be aware that if we dictate the terms of the protocol
behavior, then we're asking people to target new development against our rest
solution. While I'm not saying that we can't do something novel in this regard, I
just having a hard time separating out what's being proposed in the near term. I also
want to make sure that we're not reusing web services models for the wrong reason.
As for data binding, I similarly don't want us dependent upon xml document models.
There are plenty of other ways of generating xml through Teiid (sql/xml, xquery, direct
from sources, etc.). We can also add a general purpose inverse to jsonToXml regardless of
the rest efforts.
Ramesh..
On Tue, 2011-05-03 at 13:41 -0400, Steven Hawkins wrote:
> ----- Original Message -----
> > 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?
> >
>
> By legacy I mean someone has an existing RESTful service not
> implemented through EDS, but wants to do it through EDS - the common
> virtualization use case.
>
> > 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.
> >
>
> Sure, a long term goal would be to provide some general restful
> interface to relational that can include all sorts of novel querying
> capabilities. Whether someone else has a license friendly way of
> doing that or we develop it ourselves is an open question. My
> concern however is still around the next EDS feature release. There
> are all sorts of things we could do, but we have a rather short
> window to hit that release.
>
> > 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).
>
> No I am not in favor of introducing a rest meta-model. I would
> either be in favor of starting off with just the assumed URI
> /{catalog}/{schema}/{procedure} mapping (it would still be open what
> the data binding would be), or using the pending generic extension
> metadata feature to set properties (similar to resteasy annotations)
> on the procedure/params/results as to what their restful mapping
> should be.
>
> > 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?
>
> Since the web services model at it's core is just a set of
> procedures the only difference with any other procedure is that the
> output is known to be xml.
>
> >
> >
> > 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(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
> > > _______________________________________________
> > > teiid-dev mailing list
> > > teiid-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/teiid-dev
4:10 p.m.
New subject: [teiid-dev] REST Interface to TEIID
Format options should be specifiable.
GET /{catalog}/{schema}/{table}?column1=value&format={xml/json/csv...}
--Jimmy
On 5/2/11 4:18 PM, "Steven Hawkins" <shawkins(a)redhat.com> wrote:
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
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
3:54 p.m.
New subject: [teiid-dev] REST Interface to TEIID
The idiomatic RESTful approach would not specify the desired format in the URL, but to
instead use the "accept" HTTP header to specify the acceptable MIME types the
client desires:
GET /{catalog}/{schema}/{table}?column1=value HTTP/1.1
accept: application/json,application/xml,text/xml
If only one media type is desired, then just list one.
This is a far better option than specifying
On May 3, 2011, at 9:10 AM, Schappet, James C wrote:
Format options should be specifiable.
GET /{catalog}/{schema}/{table}?column1=value&format={xml/json/csv...}
--Jimmy
4:19 p.m.
New subject: [teiid-dev] REST Interface to TEIID
What we really need is something like this
http://htsql.org/
This seems really good on cursory look and extensive. Their license
seems restrictive, we need to explore options here.
Thanks
Ramesh..
On Mon, 2011-05-02 at 15:10 -0400, Ted Jones wrote:
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
5013
days inactive
5016
days old
teiid-designer-dev@lists.jboss.org
13 comments
5 participants
participants (5)
-
Ramesh Reddy -
Randall Hauch -
Schappet, James C -
Steven Hawkins -
Ted Jones