Amazon Simple Email Service（SES）-SMTPインターフェイスまたはSES APIを使用する必要がありますか？
私はAmazonSESを初めて使用しますが、プログラムでメールを送信する方法は2つあります。
- SES API（ http://docs.aws.Amazon.com/ses/latest/DeveloperGuide/send-email-api.html ）
- SES SMTPインターフェース（ http://docs.aws.Amazon.com/ses/latest/DeveloperGuide/send-using-smtp-Java.html ）
それぞれの方法の長所と短所は何ですか？私には互換性があるように見えますが、SESの経験がある人から聞いてみたいと思います。
私自身の要件として、ユーザーがやり取りするときに、トランザクションメール（領収書、アカウント確認など）と通知メール（「新しいメッセージがあります」、ステータスの変更など）をユーザーに送信します。私のウェブとモバイルアプリ。可能であれば、これらすべての送信メールの履歴を保持したいと思います。
SES APIは、SMTPインターフェイスであるAWSに接続します...まあそれはSMTPです。
将来、AWSから移行する必要があると予測していますか？アプリケーションはすでにSMTPを別の電子メールサーバーと通信していますか？
現在のアプリケーションによっては、SMTPを使用する方が簡単な場合があります。
ゼロから始めて、AWSから移行する必要がないと予想される場合は、おそらくSESAPIを使用する必要があります。
SES APIを使用すると、SDKを使用するため、インスタンスでロールを使用できます。構成のパスワードを処理して保存する必要がないため、パスワードを変更する手間がかかりません。
私は小さなプロジェクトをリリースしました https://github.com/loopingz/aws-smtp-relay ローカルホストSMTPからSES APIにリレーします。これにより、SMTPのみを処理するレガシーアプリケーションをより通常のSESAPI
スループットの向上に関するAmazonのドキュメント から、APIの利点の1つは、スループットを向上させるために永続的なHTTP接続を使用するオプションです。これはSMTPオプションでは使用できません。
これとは別に、APIとSMTPの間に他の大きな違いを見つけることができませんでした。
それらは私には交換可能のようです
それは公正な分析です。私は両方を使用します-新しいコードにはAPI、SMTPの話し方をすでに知っている既存のコードにはSMTP。どちらにしても、強いケースは見つかりませんでした。
どちらのインターフェースも履歴を保存しません。自分で行う必要があります。一部のレガシーコードで使用するために取り組んでいるメカニズムの1つは、アプリとSES間の相互作用をキャプチャするSMTPプロキシであり、必要に応じて後で取得できるように、SESメッセージIDをS3キーとして使用してトランザクション全体をS3に保存します（進行中の作業、より差し迫ったプロジェクト）。
少なくとも、SESから返されたメッセージIDを保持し、バウンス、配信、および苦情の通知を構成して、フィードバックを得る必要があります...これはどちらのインターフェイスでも同じように機能します。