There is no one-size-fits-all answer here.
It all begins with the realization that microservices are not even necessarily web services. It's definitely the most common scenario, but not the only one. And when you don't have a web component, you'll obviously have to find another way to handle the communication.
Should these microservices share a database?
This is not a great idea, as this infringes on the independence of the microservices. There's two possibilities here: either the microservices share some of the db content, or they share nothing.
If they share something, then your microservices cannot be independently deployed, because any change to the shared data forces a redeployment of both services. In this case, they cease to be "true" microservices.
If they don't share anything, then there's no reason to put it in the same database (additionally, then they don't communicate using the database either). It's better to separate the dbs then, as it means that you can take one db down (or restore it) without affecting the other.
Should they communicate over REST?
If your microservices are not web services, it's obviously not possible.
For web services, you generally use the web component for communication with consumers anyway, so it makes sense to reuse this for communication between web services. That's not necessarily REST, any data transmission format would work here. But REST is the most common.
Should they duplicate data in each of their own databases?
Usually, the point of microservices is that each microservice stores its own data. There's not a lot of duplication going on. You'd expect all of a person's data to be contained in the person service, and the order service only stores a reference to the person ID.
However, it might be the case that you save a historic table of orders which contain personal information that should be kept the same even if the person's data changes in the future. For example, if I change my address today, when I look up an order I made last year, it should still show the address that I used back then.
It may become relevant here to copy the person's data into the order, so that the order service can keep it for historical purposes.
However, if I never change my personal data, that does indeed mean that the same data is found in both the person service and the order service's databases. We can argue that their purpose is different (current information vs historical snapshot, or person data vs order data) but the values are possibly (and likely) the same.
But this is no different than if you were using a monolith application without microservices. The same principle of making historic copies of data would apply. So this isn't really microservices-related in and of itself.
In summary, you tend not to duplicate data between microservices, unless a valid reason to do so exists.