Like for example,
/api_2/login writing in the same table of the same database.
No. Apis are microservices, microservices are supposed to be contained. So they have their own database and don't call other peoples.
Of course this is an ideal and maybe you have very fine grained apis which are more like parts of a microservice. (or a massive fat API that does everything, but that's what people are trying to get away from)
The key thing you are trying to avoid is that changes to API X break random API Y. You want to be able to upgrade and change each API without affecting the others. If you know that the only way a DB is accessed is through its API then you have a controlled 'surface area'. As long as you keep that working you don't have to worry that some sneaky backdoor access will break.
Of course this has nothing to do with REST per-se. But I think I know what you mean.
So in your senario, instead of having two apis each with a login method, I would have three apis.
- auth api
- api 1
- api 2
Users login on the auth api and get the auth token which they pass to the other apis. The other apis check the token signature and claims to auth the user.