Well maybe one just per default escapes the data as it should be.
This sounds like integration test case since you guys are testing the rest API and usually an API is only to be seen as what it returns not how it behaves internally. You test against the interface in other words .... your REST-API should not care if something is in the database. it should only be concerned with the defined behaviour of the REST-API.
So for this intent I would mock the BL below because it's a response behaviour and you can purposly force all states it should represent without the overhead of actually doing anything of great calculation costs below. Unless you did not loosely couple then you should use an in memory SQL-Lite database with fixtures to mock, so at least the overhead is less and you can throw away the database after testing.
if you want to test your business-logic you have to test it as a functional test which is to ensure it works as intended. this is where you actually should compare the state of your application instead of the communication with your application.
Doing unitests afterwards is a pain in the ass esp since doing unitests from the beginning helps you to create better software design. That's to me the main purpose of it, the other things like guarantees are nice, but tests just only ensure quality in the metric around stability not the others.
Maybe just start with only blackboxing the API since this is your current task and afterwards go in for the business logic. Actually you should've done it the other way around but you have to start somewhere and this is an achievable goal.
at least in my opinion