We could either say it was successfully attempted (lol), that it was successfully added to the mail queue (my vote), or just block and tell them whether it succeeded or failed.
Mail Queue
How about we return to them the saved *Email (as JSON) so they have the ID and as to return immediately. We can then save a corresponding EmailStatus object (see #19) then allow them to query the server to check the status (perhaps via GET requests to /email/{id}/status).
Web Hooks
We could also have web hook-like functionality, where the request could include an optional callback_url field that the email service POSTs to once the status of the attempted email sending has either succeeded or failed (the JSON in the POST could say which, so I guess it should be an EmailStatus).
Blocking Option
We could also provide an option where the sending is synchronous and the remote client waits till the email has been sent. But since there would be no guarantee that the send would either succeed or fail while the client was waiting -- especially before it timed out -- this might not work very well. In practice it would work for our use case, but I think it'd be bad practice to get used to doing things that work for small projects but would never work at scale.
I know what would be good practice though (for you using select): the call to .Send() could wait up to 30 seconds, at which point the EmailStatus is returned to the client with whatever status -- QUEUED, PENDING/SENDING, SUCCESS, FAILED. Then the client could at least do GETs to /email/{id}/status to find out what happened (and could also include a callback_url to get the response web hook-style).
We could either say it was successfully attempted (lol), that it was successfully added to the mail queue (my vote), or just block and tell them whether it succeeded or failed.
Mail Queue
How about we return to them the saved *Email (as JSON) so they have the ID and as to return immediately. We can then save a corresponding EmailStatus object (see #19) then allow them to query the server to check the status (perhaps via GET requests to
/email/{id}/status).Web Hooks
We could also have web hook-like functionality, where the request could include an optional
callback_urlfield that the email service POSTs to once the status of the attempted email sending has either succeeded or failed (the JSON in the POST could say which, so I guess it should be anEmailStatus).Blocking Option
We could also provide an option where the sending is synchronous and the remote client waits till the email has been sent. But since there would be no guarantee that the send would either succeed or fail while the client was waiting -- especially before it timed out -- this might not work very well. In practice it would work for our use case, but I think it'd be bad practice to get used to doing things that work for small projects but would never work at scale.
I know what would be good practice though (for you using
select): the call to .Send() could wait up to 30 seconds, at which point theEmailStatusis returned to the client with whatever status -- QUEUED, PENDING/SENDING, SUCCESS, FAILED. Then the client could at least do GETs to/email/{id}/statusto find out what happened (and could also include acallback_urlto get the response web hook-style).