Yes, separating this logic is tedious, but it's core to the concept and it scales just fine. If every time you want to enable/disable an object you simply writ

Yes, separating this logic is tedious, but it's core to the concept and it scales just fine. If every time you want to enable/disable an object you simply write an SQL update query, if you ever want to add any other requirement when an enable/disable occurs (example: you want to record the reason why an object is enabled/disabled) you've now cornered yourself into a situation where you need to identify all the code where you've written the SQL update query. A RESTful API makes a lot of sense when dealing with plain data, but starts making less sense when you're attempting handle full fledged use cases. However, your core API logic should be separated from whatever network layer exposure you're giving your API (and ideally should handle endpoint negotiation for you)