我正在尝试开发一个REST API web服务。我有一个关于如何处理用户激活电子邮件的问题。目前，API服务处理电子邮件发送。
以下是我目前拥有的流程：
这里是我目前看到的问题：
由于API服务目前正在发送电子邮件，因此客户端应用程序无法控制电子邮件的外观和感觉。而且电子邮件中可能有应该指向客户端应用程序的URL。
另一种选择是，代替API服务发送激活电子邮件，它将返回激活密钥给客户端应用程序。然后，客户端应用程序将能够向用户发送激活电子邮件。
我看到这种策略存在两个问题：
您认为处理这个问题的最佳方法是什么？
我希望允许客户端应用程序定制他们的电子邮件，并包括特定于客户端的URL（激活页面）。
TL;DR
为开发者创建一个小型服务，让他们在POST到您的激活API时声明要使用哪个模板。
问题摘要：
每次电子邮件都不需要看起来都不同。所以没必要在POST请求中附带电子邮件格式。
可以尝试以下两种方法之一：
1 创建一个单独的API端点来定义模板，让客户端应用程序在POST请求激活时选择其中一个。
这种方式并不完全安全，特别是如果你想接受来自客户端应用程序的HTML时，会带来挑战。
推荐的解决方案：
2 为开发者创建一个工具（位于他们获取API密钥的同一网站上），该工具接受模板并帮助创建它们。客户端应用程序在POST请求激活时可以选择其中一个。请求正文的片段类似于：
...
"template": "foobar-app",
"fields": {
"title": "Welcome to foobar app",
"username": "jim78"
}
...
字段中不允许使用HTML。
这使您可以使用开发人员准备的预定义模板，由您的电子邮件发送服务使用，并且客户端应用程序中的任何错误都不会导致电子邮件变得不安全。此外，您还可以获得一个地方，在该位置可以处理和测试模板。（开发人员可以将它们发送给自己进行调试 - 制作电子邮件模板是很糟糕的，请相信我）
将来，您将能够更好地支持您的开发人员/客户，并准备一组在多个邮件客户端中测试过的工作模板。
我会在第二步中向服务器发送额外的帖子数据：
"mail":{
"placeholder":"someStringChoosenByClientWhichWillBeReplaceByActivationCode",
"subject":"Hey there, please activate",
"ishtml":false,
"body":"SSdtIHRyeWluZyB0byBkZXZlbG9wIGEgUkVTVCBBUEkgd2ViIHNlcnZpY2UuIEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IGhvdyB0byBoYW5kbGUgdXNlciBhY3RpdmF0aW9uIGVtYWlsLiBDdXJyZW50bHksIHRoZSBBUEkgc2VydmljZSBoYW5kbGVzIGVtYWlsIHNlbmRpbmcu"
"attachments":[
{
"content-type":"image/png",
"filename":"inline_logo.png",
"content":"base64_data_of_image"
}
]
}
"ishtml":false,），这取决于您的应用程序以及您想要花费的时间。允许客户管理自己的电子邮件模板。当他们发布新用户注册时，允许他们指定要使用哪个模板。然后您的应用程序将发送电子邮件消息，但客户可以控制其外观。
POST /email-templates
{
"subject": "Complete Your Registration",
"body": "<html>Follow this link to complete your registration: {activationLink}. It is valid for 45 minutes.</html>"
}
POST /registration-requests
{
"name": "John Q. Public",
"emailTemplate": "/email-templates/45"
}
我认为正确的方式是向客户端公开激活密钥，让其自行处理。
您还可以添加另一个端点来发送激活密钥给用户。
返回用户（URL类似于User/{userid}，其他资源URL类似于User/{userid}/ActivationKey）。
User (POST)
这可以返回当前用户和其他资源，如电子邮件、激活等。 有关密钥的信息（如日期、过期等），请参阅相关文档。
User/{userid}/ActivationKey
从那里，你可以用以下方式扩展它：
预览激活邮件：
User/{userid}/ActivationKey/Email (GET)
更新激活电子邮件的模板、SMTP服务器等电子邮件相关内容：
User/{userid}/ActivationKey/Email (PUT)
User/{userid}/ActivationKey/Email (POST)
如果需要的话，您可以列出所有发送的电子邮件并在另一个端点中预览它们。
User/{userid}/Emails (GET)
User/{userid}/Emails/{emailid} (GET)
我加入了nauktur的想法，让客户发送电子邮件模板给您。(并且+1，因为我同意邮件“开发”的糟糕程度)。
但是为什么要这么复杂？客户端应用程序意味着开发人员，所以为什么不让他们提供您的默认模板（带有HTML），让他们随意玩耍如果他们想的话，然后将他们喜欢的版本发送给您？
对您来说并不需要太多工作（只需在客户表中添加一个新字段和一个新路由），而对他们来说则提供了很多选项。
以下是一个基本示例，我们将公开一些参数，以便他们可以在不必了解它们的情况下玩弄HTML：
app.nameapp.descriptionactivation_codeuser.* 注册信息基本模板
{
title: "Your activation code for %{app.name}",
body: "<p>Hi, you've been registered on %{app.name}.
<p>%{app.description}</p>
<p>Follow <a href="%{activation_code}">this link to confirm your inscription</a>."
}
注册新模板
然后客户说：“我更喜欢一个更简单的邮件，但是我希望他的名字在里面！”
[PUT] /api/email/templates/client_id
{
title: "Your activation code",
body: "<p>Hi %{user.fullname}, Follow <a href="%{activation_code}">this link to confirm your inscription</a>."
}
在这里，让他们玩一下 HTML 吧，它允许更多个性化设置。
除非他们搞砸了，不然对客户没什么损害，毕竟他们是自己的客户。
安全问题
有人指出攻击者可能会访问客户端应用程序的令牌，并在模板中注入恶意内容。首先，如果令牌泄漏，风险已经非常高了，这可能是您最不担心的问题。但是，如果您担心这个问题，禁止使用 img 标签，并使 a 标签的内容与 href 属性相匹配即可解决问题。