3 ms·

Why isn't there an HTTP protocol like "Query:" or "SQL:" such that drivers and ODBC/JDBC are not required to talk to a typical database? In other words, a datab

by tabtab 4y ago

Why isn't there an HTTP protocol like "Query:" or "SQL:" such that drivers and ODBC/JDBC are not required to talk to a typical database? In other words, a database web service standard. Here's a sample of what the XML could look like: https://www.reddit.com/r/Database/comments/p21u5d/standard_query_web_service_draft_proposal/ https://www.reddit.com/r/Database/comments/p21u5d/standard_q...

tacostakohashi 4y ago
Probably because a bunch of these databases, and odbc, predate http and "web services" by many years.
- tabtab 4y ago
  It generally takes roughly 5 years for such standards to trickle into common systems. But separate software could make a server gateway/portal to those database products without it. In other words, a server-based adaptor. Database-vendor-specific services could be fairly easily built in say PHP or Python. They'd still conform to the standard (using XML and/or JSON), but only implement a gateway for specific database brands. It's a start...
  - tacostakohashi 4y ago
    Sure, that could be done... but it would be dramatically slower that any of the existing drivers. As much as the vendor drivers / odbc / jdbc have their annoying quirks, the wire protocols are pretty efficient.
    - tabtab 4y ago
      It could have a binary format option (in addition to those formats listed). But also many kinds of apps don't need heavily compressed/compact data transfers. The "old" way won't go away, just have an alternative.
      - tacostakohashi 4y ago
        Ok, but they already have a binary format... What is the advantage of your hypothetical binary format (which doesn't exist), (in addition to those formats listed), over the binary formats which have existed for decades?
  - Someone 4y ago
    Adding a layer slows things down and uses more memory, even if just a tiny bit, but for large result sets, I fear it will be a lot. In addition it likely initially a) will be buggy and b) won’t support every feature of every vendor. I think that’s a hard to win battle.
newaccount74 4y ago
HTTP is stateless, whereas most database connection protocols are stateful. So if you use HTTP, you need a lot of boilerplate on the client side to manage that state (eg. prepared queries, transactions, session parameters).
alamb 4y ago
For completeness, FlightSQL[1] (as mentioned elsewhere in this thread) aims to provide such an HTTP based protocol https://arrow.apache.org/blog/2019/10/13/introducing-arrow-flight/ https://arrow.apache.org/blog/2019/10/13/introducing-arrow-f...

by tabtab 4y ago

tacostakohashi 4y ago

Probably because a bunch of these databases, and odbc, predate http and "web services" by many years.

tabtab 4y ago
It generally takes roughly 5 years for such standards to trickle into common systems. But separate software could make a server gateway/portal to those database products without it. In other words, a server-based adaptor. Database-vendor-specific services could be fairly easily built in say PHP or Python. They'd still conform to the standard (using XML and/or JSON), but only implement a gateway for specific database brands. It's a start...
- tacostakohashi 4y ago
  Sure, that could be done... but it would be dramatically slower that any of the existing drivers. As much as the vendor drivers / odbc / jdbc have their annoying quirks, the wire protocols are pretty efficient.
  - tabtab 4y ago
    It could have a binary format option (in addition to those formats listed). But also many kinds of apps don't need heavily compressed/compact data transfers. The "old" way won't go away, just have an alternative.
    - tacostakohashi 4y ago
      Ok, but they already have a binary format... What is the advantage of your hypothetical binary format (which doesn't exist), (in addition to those formats listed), over the binary formats which have existed for decades?
- Someone 4y ago
  Adding a layer slows things down and uses more memory, even if just a tiny bit, but for large result sets, I fear it will be a lot. In addition it likely initially a) will be buggy and b) won’t support every feature of every vendor. I think that’s a hard to win battle.

newaccount74 4y ago

HTTP is stateless, whereas most database connection protocols are stateful. So if you use HTTP, you need a lot of boilerplate on the client side to manage that state (eg. prepared queries, transactions, session parameters).

alamb 4y ago

For completeness, FlightSQL[1] (as mentioned elsewhere in this thread) aims to provide such an HTTP based protocol https://arrow.apache.org/blog/2019/10/13/introducing-arrow-flight/ https://arrow.apache.org/blog/2019/10/13/introducing-arrow-f...