5 ms·
Why not just accept SQL? It's a matter of contract. With REST APIs you specify a contract, it gets robust with time, and other software can expect only what's i
by aljarry 4y ago
Why not just accept SQL? It's a matter of contract. With REST APIs you specify a contract, it gets robust with time, and other software can expect only what's in the contract.
SQL allows you to run arbitrary functions over data in the database, so the whole schema and parts of the content in a way become your contract - and your options to modify the schema (or how you use the database) get very constrained.
- dragonwriter 4y agoYou can limit the visible schema, and thus the contract, per role with SQL.
- aljarry 4y agoThat's a very good point!
- officialchicken 4y ago>Why not just accept SQL? Sanitize your inputs. I'll let little bobby tables link to the XKCD
- jmull 4y agoWho says don't sanitize inputs? I'm just suggesting to not invent another query language, especially where a rather obvious and natural one already exists. You can and should sanitize untrusted input regardless.
- lelanthran 4y agoYeah, but this particular contract/API is pretty much "run arbitrary select/insert/update/delete statements" anyway! If you're using the postgrest language your options to stabilise the interface are minimal anyway, so why not just go with SQL and a whitelist?
- aljarry 4y agoYes, but the REST vs SQL forces a specific API for changes. REST - update/delete a specific record. SQL - update/delete based on a filter, or a query result. I can do `set a = b` for all rows in the table, which may be needed internally, but it's a pretty bad external interface.