[ta-run]

SQL-like queries in the request body seem like a bad idea, what are the security implications and how do we protect against it?

Or will the QUERY method end up with the same fate as GraphQL - wherein it's more effective and "secure" in a server-to-server setup and the client only deals with REST.

[crooked-v]

QUERY has nothing to do with the actual contents of the request body beyond "it is hashable text". That could be JSON, GraphQL, weird SQL cousins, or anything else.

[ta-run]

Yeah, figured that out in thanks to another thread on here. I got confused as all the examples were primarily sql ones.

[9dev]

How is that less secure than a REST API Frontend to an SQL database, like PHPMyAdmin?

I don’t think anyone suggests we all open our databases to the web; but if you choose to do so, or if you happen to work on a modern database, like Elasticsearch or CouchDB, which accept queries via HTTP, now there’s a better way to implement queries in regard to caching.

That being said: I’ve been wondering for a long time what a backend API could look like that used SQL instead of JSON as the query format - not to pass it to the database verbatim, but with an application layer that speaks SQL, applies business logic, queries the database, and responds in SQL. That would save a lot of reinvented wheels in terms of filtering, ordering, joining, and so on, and give developers a query language they already know. And suddenly, having a QUERY method available sounds useful, too :)

[sarthak-ag]

It's just an example, not a production use case.

[ta-run]

Yeah, I mean, I get that but eventually? no?

[baq]

Why eventually? It’s a sad reality for quite a few of us here right now and has been for quite some time