First rule of discussing where to put "business logic":
No one can agree what "business logic" actually is!
My view is:
All code you write to create software for a company is "business logic". This includes DDL. Meaning your table definitions are business logic.
So unless your schema is a giant "thing" table that stores JSON (or similar) you've got "business logic" in your database whether you have stored procedures or not. So a statement like "no logic in the database" is nonsense.
Remember: you can do a lot with basic primary, unique and foreign keys. The more you do with these, the less code you have to write. The less code you write, the less chance of bugs. So you should use these where possible.
For an intro to how to do this I thoroughly recommend developers read The Database Programmer blog. This shows how you can create a school timetabling application with basic database constraints. This enforces "complex" rules like "a student or teacher can only have one class at a time":
https://database-programmer.blogspot.co.uk/2008/09/comprehensive-table-of-contents.html A lot of your code then becomes simple SQL with appropriate error handling.
This still leaves the debate over where this SQL belongs. Toon Koppelaars has compelling argument for placing this in PL/SQL: performance. There are many optimizations for SQL in PL/SQL which make it much faster than placing it in Java (or whatever).
You can see him discuss his findings at:
https://www.youtube.com/watch?v=8jiJDflpw4Y As he says, this is because with PL/SQL you are in the database's "living room". Whereas other technologies must come in through the front door. This means you can actually use
less DB server resources using PL/SQL!
I'd also like to point out that REST and PL/SQL aren't mutually exclusive options. You can use ORDS to expose PL/SQL as REST endpoints. Tim Hall has good instructions on how to do this at:
https://oracle-base.com/articles/misc/oracle-rest-data-services-ords-create-basic-rest-web-services-using-plsql In short: using constraints, stored procedures and other features available in the database will help you build better, faster applications with less code.
Sounds like a winner to me ;)
Further reading:
Bryn Llewellyn's "Why PL/SQL?" paper:
https://blogs.oracle.com/plsql-and-ebr/why-use-plsql Toon Koppelaars "Helsinki Declaration":
https://thehelsinkideclaration.blogspot.co.uk/