There are different ways for looking at this.
Viewpoint: only write value-add tests. Test the behaviour that “adds value” to the overall software. Don't bother mocking and isolating everything if that's too much effort. If your REST controller has logic for mapping exceptions to return codes, then do write a test for that. But if that behaviour is part of your web framework, you likely shouldn't bother. You can trust that other components are doing their job correctly.
Viewpoint: only test externally visible behaviour. A REST client cannot assume how the server is architected internally, and doesn't know (or care) about whether the startCollection() method was called. If it is important that the
POST /add endpoint return an error if
POST /start was not invoked previously, the REST controller needs a test for that.
Personally, I think that overly detailed unit tests with lots of mocking can often be a waste of time. Yes, TDD is very nice. Yes, unit testing complicated code is awesome. But a lot of code is not complicated, it's just glueing different parts together. Testing such glue code in isolation would require an insane amount of mocking. That effort often stands in no relation to the value of these tests. Such isolated test also fail to exercise the part of the code where, anecdotally, most bugs happen: the interfaces between components, not the logic in the components themselves.
What might work better is tests for the external behaviour of the software, especially end to end tests. That might also be an integration test, depending on where you draw the component boundaries in your architecture (not necessarily at the class level!). These tests make it more straightforward to demonstrate that the system under test provides certain business value, for example that your REST API supports a collection lifecycle for clients of the API. Indirectly, this might also test internal details like the add() method raising an exception in illegal states. If an internal component is so complex to merit more detailed testing, writing unit tests to thoroughly exercise that component in isolation is possibly much more efficient and a good idea as well. So the idea would be to focus testing effort where it produces the most value, but not aiming for 100% unit test coverage.
That said, if unit testing is painful because lots of mocks, this doesn't necessarily mean that the tests aren't worth it – it can also mean that the design is not very testable. In particular, I find classic OOP style architectures to be pretty difficult to test because the object graph quickly gets out of control, whereas the data flows are often simpler in more functional designs.