API的使用者不知道也不应该知道您使用的是哪种数据库。
返回给他们的错误应该封装所有的错误，并以某种标准格式用一个好的HTTP状态代码明确地告诉他们什么是错误的。
泄漏给用户的数据库特定错误通常应被视为bug。

两者皆有。

您应该编写代码，在尝试插入之前检查电子邮件是否存在。
但是，如果该检查未找到任何电子邮件，则由于争用条件，您仍可能收到错误。例如，在检查电子邮件和继续插入行之间的短暂时间内，其他某个并发会话可能会使用该电子邮件插入其自己的行。因此，在这种情况下，即使您已检查并发现该电子邮件不存在，您的插入操作也会收到重复关键字错误。
因为如果使用带有auto_increment主键的表，失败的插入会生成一个自动递增的值，然后丢弃它。
这看起来像是一种罕见的、微不足道的浪费，而且，我们不关心自动递增的id是否连续。
但我确实帮助一个客户修复了一个应用程序，他们遇到了一个问题，新用户在成功创建唯一帐户之前尝试了1500次，因此他们“丢失”了每个帐户的数千个自动递增id，几个月后，他们耗尽了有符号整数的范围。
我推荐的修复方法是首先检查电子邮件是否存在，以避免在找到电子邮件时尝试插入，但您仍然必须处理争用条件以防万一。