In the real world, it is conceivable that you could have two people with the same last name, first name and date of birth.
But, in moderate sized databases, it is more likely that it would be a duplicate of the same person. To prevent duplicates from being created, our user interface requires the user to first search for the person. If the record they desire exists, the user can select it. If not, they can add it. They are allowed to add people with the same name and dob if they need to - but usually, they want the existing record.
The key is, the API should allow the user to create the new record, but ideally, I'd like to require them to search first.
In an API situation, I would like to be able to require the user to search first and then add it if necessary, but I'm not sure how an API typically handles this kind of situation. What is typically done?
Because the rest architectural style uses stateless requests, you can't really do what you are asking here.
Which is to say, you might imagine a website that walks you through the domain application protocol: you fetch a bookmarked URL; that page includes a link which you follow to a search form; you submit the form with your search criteria, and it returns a list of possible matches and a link; following the link takes you to the "create new record" form; the user submits this form to request that the server create a new user.
But semantically, this last request is no different that what would be generated by a client that had the "create new record" URL hard coded into it.
You can potentially make that URL harder to guess by encoding information into it. For instance, during the search you could encode the key search terms into the URL, to pass them along to the form and ultimately the form submission, at which point you can check if the record details submitted match the previous search.
One of the advantages in hypermedia API is that, because the clients aren't using the semantics of the URI spellings, the server can encode information into those URI for later use. Unfortunately, the hypermedia constraint has had trouble gaining mind share as a constraint on "RESTful" API. And of course this design doesn't actually protect you against clients that are really good guessers.