>Server side APIs hamstring external developers and users. I can't build a dynamic query and get the data I want, the way I want it if I can only execute simple API calls. While I recognize there might be a way to intercept the ODBC connection between an application and a database server and change the SQL going to the server, I can't get over the idea that it is called SQL Server, not SQL API server.

As a developer I feel the same - just shoot the hackers and let me implement driest and most succinct code ;-)

But as most operations are either simple CRUD or count(), sum() calls working on a single table, I think those should be created sever side - with parameters, as the client side gotten text values might have been corrupted.

Having an obscured back door in the server side API obscure(In: JSON, Out: JSON) accepting those dynamic queries embolded above does not add any more risks than executing those calls directly, but marks the dangerous area server side clearly - it becomes a wart you might tighten up sooner than if you accept the pure_parameterized_SQL request metaphore.

Post Snowden security scrutiny has shown too often that transport layers requested by standard methods to be safe were not. And client side code cannot be considered safe, as there are hackers out there knowing many more debug tricks than me. As a Web/JS client today often cannot be ruled out forever, creating an architecture not cracked in the first 5 minutes by using web debug tools grows in need similar to the realization of SQL injection risks last century.

I still think a tiny relational/SQL API is better than ORM/nHibernate influenced structures, but the need for SOME server side sanitation of requests is obvious in my view on how to build net-accessed central storage. Does not ease any ideas of building SQLite-based client side DB caches similar to vfp cursors ;-))