3 ms·

> For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then r

> For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it. Every single SQL server allows a client to dictate the query. Furthermore, not all queries are SQL queries.

hparadiz 4mo ago
[flagged]
- flanked-evergl 4mo ago
  What does "some random third party" have to do with any of it? An SQL server can expose HTTP directly. SQL is not the only query language that exists. SPARQL's standard protocol for sending Queries uses HTTP[1], and yes, of course it allows clients to define the query that it sends over HTTP. HTTP QUERY would be ideal for SPARQL queries. There are also many unprotected SPARQL endpoints that you can use without any authentication [2][3]. [1]: https://www.w3.org/TR/sparql11-protocol/#query-operation https://www.w3.org/TR/sparql11-protocol/#query-operation [2]: https://sparql.dblp.org/ https://sparql.dblp.org/ [3]: https://data.europa.eu/en/about/sparql https://data.europa.eu/en/about/sparql
  - hparadiz 4mo ago
    This thread is for an RFC that is less than 3 pages and solves no problems that exist. I'm tired of having to pretend like every idea on the internet is a good one.
    - kortex 4mo ago
      This RFC (the concept behind it) has been in the works in one form or another since 2008 > The HTTP SEARCH method was first formally proposed in November 2008 within RFC 5323. > Before it became a full RFC, the proposal progressed through the IETF under the working group draft name draft-ietf-httpbis-safe-method-w-body. Its formal journey began in March 2021 as an adaptation of the older SEARCH method (from WebDAV's RFC 5323), before being renamed explicitly to QUERY in later draft revisions. There's no "pretending" this is a good idea, a ton of very smart people have spent a tremendous amount of effort refining this solution. It's incredibly well thought out.
      - hparadiz 4mo ago
        The test of an RFC is whether people use it. Your example doesn't inspire confidence.

hparadiz 4mo ago

[flagged]

flanked-evergl 4mo ago
What does "some random third party" have to do with any of it? An SQL server can expose HTTP directly. SQL is not the only query language that exists. SPARQL's standard protocol for sending Queries uses HTTP[1], and yes, of course it allows clients to define the query that it sends over HTTP. HTTP QUERY would be ideal for SPARQL queries. There are also many unprotected SPARQL endpoints that you can use without any authentication [2][3]. [1]: https://www.w3.org/TR/sparql11-protocol/#query-operation https://www.w3.org/TR/sparql11-protocol/#query-operation [2]: https://sparql.dblp.org/ https://sparql.dblp.org/ [3]: https://data.europa.eu/en/about/sparql https://data.europa.eu/en/about/sparql
- hparadiz 4mo ago
  This thread is for an RFC that is less than 3 pages and solves no problems that exist. I'm tired of having to pretend like every idea on the internet is a good one.
  - kortex 4mo ago
    This RFC (the concept behind it) has been in the works in one form or another since 2008 > The HTTP SEARCH method was first formally proposed in November 2008 within RFC 5323. > Before it became a full RFC, the proposal progressed through the IETF under the working group draft name draft-ietf-httpbis-safe-method-w-body. Its formal journey began in March 2021 as an adaptation of the older SEARCH method (from WebDAV's RFC 5323), before being renamed explicitly to QUERY in later draft revisions. There's no "pretending" this is a good idea, a ton of very smart people have spent a tremendous amount of effort refining this solution. It's incredibly well thought out.
    - hparadiz 4mo ago
      The test of an RFC is whether people use it. Your example doesn't inspire confidence.