Do RESTful endpoints eliminate the need to SQL triggers?
Triggers are supposed to execute after a certain event. Would moving to RESTful api endpoints conceptually eliminate the need for SQL triggers?
The reason being, effects triggered from an event can be managed purely by well constructed RESTful endpoints. This includes logic that would be triggered in a SQL trigger function. It seems redundant to have both a RESTful endpoint and a separate trigger for handling events.
Are your restful endpoints the only thing talking to the database?
If 100% of the events that trigger the database go through RESTful endpoints then you have a way to detect them. Otherwise you’ll miss events.
Some events are emergent in the DB. A RESTful event makes you delete a row in table A. That cascades to a delete in table B. If Table B has a trigger on delete it’s easy to miss that logic if you move to RESTful code.
But there are certainly applications that can be done completely free of database triggers.
The drawback of DB triggers is they move business logic into the DB making it harder to replace the DB later. The advantage is they can minimize traffic over the DB connection.
But sure, you can definitely eliminate triggers. Just do so wisely. Push this far enough and you can find yourself writing you own DB.
Generally speaking, yes.
You only need one API layer, If you are a DBA then you make it with Views, Stored Procedures, Triggers etc. Because that's the hammer you have.
If you are a programmer your write your API in code and prevent direct DB connections from bypassing it.
The code approach is generally superior, you can horizontally scale your logic, do things that databases find hard, eg. send an email, call another api, add more complex authentication, expose the access over the internet etc.
Maybe you have some edge cases where a trigger, sproc of view can still be useful. But you should try not to have two competing API layers.
