Hacker News new | ask | show | jobs
by captain-asshat 5286 days ago
This problem has already been solved; it's called OData (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.
1 comments
alt_ 5285 days 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.

link
captain-asshat 5285 days 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.

link