4 ms·

This problem has already been solved; it's called OData (http://www.odata.org/ http://www.odata.org/). Personally, I've been using it with Microsoft's new Web A

This problem has already been solved; it's called OData (http://www.odata.org/ http://www.odata.org/). Personally, I've been using it with Microsoft's new Web Api to great benefit. It provides a very rich query API on top of basic http, and as you can see works naturally with REST services. I'm not aware of how other frameworks provide OData support, but some quick googling reveals that most web frameworks have odata libraries available. It's an incredibly bad idea to allow SQL directly, for obvious reasons (would require executing user provided SQL among other things.) I believe that having a single REST api that serves multiple front-ends (web, mobile, thick client etc) is the future as it removes the need to maintain an entirely different codebase just for a web interface. Indeed, many major websites have moved to this model.

alt_ 15y ago
> It's an incredibly bad idea to allow SQL directly, for obvious reasons (would require executing user provided SQL among other things.) Could you elaborate on this? I've been thinking about providing SQL access to a data-heavy service, but I keep hearing that you never should. (Almost) all servers have granular access-control, views can further provide limited views of the data, SQL itself is mostly declarative, which makes it possible to analyze the queries before running them, and logging and setting limits on long-running queries is standard.
- captain-asshat 15y ago
  Well, the first problem you'll run into is, which SQL implementation do you use? I think pretty much all discussion of the topic stops here since there are so many differences between the actual SQL standard and what the varios modern RDBMS' actually use. The only real way past this hurdle is to create an intermediate SQL parser that uses your own interpretation of the standard, and at this point you may as well just use OData. I'm not sure how valuable a discussion about just using the SQL implementation that comes with your RDMBS is, as doing this defeats all the effort we put into making our front ends ignorant of the underlying schema by locking the front-end into a specific SQL implementation for queries.
  - deleted 15y ago
    [deleted]
  - 6ren 15y ago
    That's a practical, real problem, yes. But something with the equivalent power of a relational algebra (e.g. SQL) seems needed, if web APIs are to be used by many different clients, and be back-compatible. It's true that some aspects are different from those problems in an enterprise that SQL were designed to address (e.g. the web crosses companies; massive numbers of users; rarely mission-critical), so perhaps SQL itself won't be the ideal solution Even if it was, the usual approach of our industrial is to invent new standards whenever possible (new firms may do this partly to lock out old ones). But it seems that the solution must be conceptually identical: an sufficiently expressive data model (e.g. relations), and a way to map between different representations with that data model (e.g. relational algebra).

alt_ 15y ago

> It's an incredibly bad idea to allow SQL directly, for obvious reasons (would require executing user provided SQL among other things.) Could you elaborate on this? I've been thinking about providing SQL access to a data-heavy service, but I keep hearing that you never should. (Almost) all servers have granular access-control, views can further provide limited views of the data, SQL itself is mostly declarative, which makes it possible to analyze the queries before running them, and logging and setting limits on long-running queries is standard.

captain-asshat 15y ago
Well, the first problem you'll run into is, which SQL implementation do you use? I think pretty much all discussion of the topic stops here since there are so many differences between the actual SQL standard and what the varios modern RDBMS' actually use. The only real way past this hurdle is to create an intermediate SQL parser that uses your own interpretation of the standard, and at this point you may as well just use OData. I'm not sure how valuable a discussion about just using the SQL implementation that comes with your RDMBS is, as doing this defeats all the effort we put into making our front ends ignorant of the underlying schema by locking the front-end into a specific SQL implementation for queries.
- deleted 15y ago
  [deleted]
- 6ren 15y ago
  That's a practical, real problem, yes. But something with the equivalent power of a relational algebra (e.g. SQL) seems needed, if web APIs are to be used by many different clients, and be back-compatible. It's true that some aspects are different from those problems in an enterprise that SQL were designed to address (e.g. the web crosses companies; massive numbers of users; rarely mission-critical), so perhaps SQL itself won't be the ideal solution Even if it was, the usual approach of our industrial is to invent new standards whenever possible (new firms may do this partly to lock out old ones). But it seems that the solution must be conceptually identical: an sufficiently expressive data model (e.g. relations), and a way to map between different representations with that data model (e.g. relational algebra).