A REST interface for a TTM database
I'm trying to design a generic REST interface for a database that broadly conforms with TTM principles. This much is easy.
POST http://api.mydomain.com/Supplier/S
{data as JSON payload}
GET http://api.mydomain.com/Supplier/S
GET http://api.mydomain.com/Supplier/S/S3
A large part of TTM deals with language features, and there are interesting questions on how to incorporate the RA into REST queries. Another time.
I need an API that is discoverable and complete -- it is the only way to access the data. So the issue I'm stuck on is how to access the schema. TTM makes vague statements about the catalog, but the kind of language constructs used in Tutorial D really are not consistent with REST principles.
I wondered if anyone has any experience or thoughts on how this should go?
Is the problem just accessing or retrieving data from the schema?
In Rel, retrieving the value of a schema/catalog relvar is no different from retrieving the value of any other relvar. Assuming the above, retrieving the list of all catalog relvars from (I assume) the Supplier database would be:
GET http://api.mydomain.com/Supplier/sys.Catalog
If the schema is directly writable, as opposed to using some Data Definition Language, then presumably you could insert/update the catalog directly. E.g.:
POST http://api.mydomain.com/Supplier/sys.Catalog
{new relvar definition as JSON payload}
You've described the obvious part. The remainder is querying using arbitrary predicates (QTY = SQRT(current_time) e.g.) and querying relational expressions that are not mere references to the database relvars. Oh yes. And POSTing to the database in some mode equivalent to multiple assignment.
REST is prone to producing a view of/interface to the database that is roughly equivalent to what we were doing with VSAM files in the 1960's and 70's. imo.
Quote from Dave Voorhis on October 22, 2018, 10:29 amIs the problem just accessing or retrieving data from the schema?
[Sorry, missed your reply. Forgot to subscribe to my own thread.]
Yes, in the first instance. I'm just thinking about how to make a 'database in the cloud' where the only access is the front door. There is no side channel through which to execute SQL, and it may not even be an SQL database. But exposing system tables as endpoints is probably the answer. There would need to be a RELVAR table and an ATTRIBUTE table, and each would describe itself (and each other).
Quote from Erwin on October 22, 2018, 7:56 pmYou've described the obvious part. The remainder is querying using arbitrary predicates (QTY = SQRT(current_time) e.g.) and querying relational expressions that are not mere references to the database relvars. Oh yes. And POSTing to the database in some mode equivalent to multiple assignment.
REST is prone to producing a view of/interface to the database that is roughly equivalent to what we were doing with VSAM files in the 1960's and 70's. imo.
It's reasonably easy to define new languages to deal with creating new values, project, restrict, sort and paging using query strings or embedded in the JSON. I think OData has most of that.
Yes, it's hard to deal with more than one relvar in a single REST query. You need a generalised query language.
The focus of the RDBMS world is on transactional enterprise business data. I'm interested in REST interfaces for the myriad other kinds of data: wide variety of data sources; personal data; data sets that are queried but rarely updated; temporary data; data transfers. I'd just like to think we could do a bit better than Excel without going straight to the Enterprise model.
Quote from dandl on November 2, 2018, 4:58 amI'd just like to think we could do a bit better than Excel without going straight to the Enterprise model.
I agree; I think we can too. I'm working on it...
...Slowly, but making some progress.
I'd really like to hear your thoughts, off list if you prefer. This is a problem I've been working on for decades in one way or another, and I know what I would like to achieve but not precisely how to get there.
Quote from dandl on November 2, 2018, 11:11 pmI'd really like to hear your thoughts, off list if you prefer. This is a problem I've been working on for decades in one way or another, and I know what I would like to achieve but not precisely how to get there.
I'm not sure I know either, but I'm trying out something and it'll be a little while before I get there. It's taking a bit longer than I thought, not because it's taking longer itself, but because I'm busy with many things.
When I get there, if it works I'll share it.
If it doesn't work, I will sweep away the humiliating wreckage and will humbly reveal why it didn't work.
I'm not quite prepared to discuss it yet. Not because I'm keeping secrets, but because some aspects are still very unformed, and I need time to think, experiment, and reflect.
I haven't thought deeply about this, and certainly the open expressions are an issue, but I think treating every possible relation-valued expression as a distinct resource is the Right Thing. Thus http://ttm.org/foo/bar retrieves the relation bar in the db foo, and http://ttm.org/foo/join/bar/baz returns bar JOIN baz. Here are some more examples:
http://ttm.org/foo/join/bar/join/baz/quux [all operators have to have fixed arity for unambiguous parsing]
http://ttm.org/foo/select/baz/(a,b,c) [note that parens are valid in URLs]
http://ttm.org/foo/rename/baz/a/this [you have to decide if this renames A to THIS or vice versa]
The flattening to URL syntax creates trouble where we would use parentheses to control nesting in more common syntax versions :
JOIN ( MINUS (A,B) , MINUS(C,D) ) <---> join/minus/a/b/minus/c/d ??????
(Note that join being associative we would surely like to have join/bar/baz/baq/bat !!!)