As for automatic testing, what you are missing is the capability to either

a. Regenerate the datastore in a very specific state during the testing phase, so you can provide each test with the required data and the required state. If we were speaking about databases, I would suggest implementing in-memory databases alongside with some sort of change logger.

b. Mock dependencies. Naively summarized, you need a way to don't depend on real data, you either mock it in memory or files, but should be possible for you to change it anytime as the code and tests evolve. 

What you are looking for is named **determinism**. For you to be able to execute tests in any order, anywhere, anytime and always obtain the same result, you need the capacity to alter the data that makes the business logic to behave in one or another way. Among other things.

> Another example would be testing authentication and other endpoints
> that require an authenticated user. So to perform those test that
> require authentication, such as a request to user/update I would need
> to have an API token ready for it, which means I must have run the
> auth/login request to get the API token and saved it somewhere to be
> used by subsequent tests. Therefore, it obviously introduces the same
> problems as the above-mentioned example, if not more.

Hell no.

You can create a default token for testing purposes. One which never expires and bound to a non-production user. For example, I have tests that help me out to create and validate JWT. Those tests are never executed as part of the testing plan. They are tools somehow. 

I use those tokens as constants in my testing code. If I have different profiles, I generate different tokens, each of which is bound to a non-real user with the expected role for the test.

> Hence the current organization necessitates a rigid sequence of tests,
> which goes against the principle of atomicity, which in turn renders
> features like parallel testing impossible. Therefore, I am keen to
> hear what is the right way of unit testing REST API to facilitate
> atomicity?

Not necessarily. Say you achieved **determinism** in your automatic testing. You still can deploy a staging environment and set it as the target for E2E or Load testing.

Basically, you need a tool that allows you to record all the calls (and order) to the API, so you can reproduce such a scenario over and over. The tool should allow you to handle responses, store info, load info, etc. 

For you to be able to reproduce the scenario (use-case) countless times, you need to reset the data. For example, if you want to reuse an email for the signup phase, you have to provide the API with an endpoint to remove the existing account and make this one the last call of all your scenarios.