Heyo,

Feel free to push back on any/everything in here! I made a bunch of breaking changes, but I think with decent justification.

The switch from String's to &str is fairly important to me. I have an application which can't move ownership of it's metadata around, and copies get expensive pretty quickly.

The builder stuff isn't particularly important at all, but it does let you avoid having to make your Mail objects mut which is nice, and this is also a super common pattern in rust. The more common pattern is to have a MailBuilder which doesn't let you have a concrete Mail until you ::build(), I can implement that if you have the appetite but I wanted to get your thoughts on this.

We could also save a ton of copypasting by using a macro to generate these methods (ala https://github.com/richo/archiver/blob/master/src/pushover.rs#L68-L74). Again, I'll happily implement that if you like.

The dynamic template data was overriding the headers and causing the personalizations to be lost. Besides fixing the assignment, we renamed the argument to be more meaningful.

Signed-off-by: Otavio Salvador [email protected]

I made the same example using sendgrid-rs and sendgrid-nodejs

const sgMail = require("@sendgrid/mail");
sgMail.setApiKey(
    "xxxx"
);
const msg = {
    to: "[email protected]",
    from: "[email protected]", // Use the email address or domain you verified above
    subject: "Sending with Twilio SendGrid is Fun",
    text: "and easy to do anywhere, even with Node.js",
    html: "<strong>and easy to do anywhere, even with Node.js</strong>",
};
//ES6
sgMail.send(msg).then(
    () => {},
    error => {
        console.error(error);

        if (error.response) {
            console.error(error.response.body);
        }
    }
)
//ES8
;(async () => {
    try {
        await sgMail.send(msg);
    } catch (error) {
        console.error(error);

        if (error.response) {
            console.error(error.response.body);
        }
    }
})();

use std::collections::HashMap;

use sendgrid::errors::SendgridError;
use sendgrid::v3::*;

#[tokio::main]
async fn main() -> Result<(), ()> {
    println!("Hello, world!");
    let mut cool_header = HashMap::new();
    cool_header.insert(String::from("x-cool"), String::from("indeed"));
    cool_header.insert(String::from("x-cooler"), String::from("cold"));

    let p = Personalization::new()
        .add_to(Email::new().set_email("[email protected]"))
        .add_headers(cool_header);

    let m = Message::new()
        .set_from(Email::new().set_email("[email protected]"))
        .set_subject("Subject")
        .add_content(
            Content::new()
                .set_content_type("text/html")
                .set_value("Test"),
        )
        .add_personalization(p);

    // let mut env_vars = ::std::env::vars();
    // let api_key = env_vars.find(|v| v.0 == "SG_API_KEY").unwrap();
    let sender = Sender::new(
"xxxx"
    );
    let resp = sender.send(&m).await.unwrap();
    println!("status: {}", resp.status());
    Ok(())
}

Hey @gsquire, I've tried to send message and it returned Ok with the following error:

{"errors":[{"message":"If present, text/plain must be first, followed by text/html, followed by any other content.","field":"content","help":null}]}

I wonder if SG returns successful status code in this case?

Hello,

I've added the option to build sendgrid-rs with the async client from reqwest. This allows you to use sendgrid-rs with async frameworks like tokio, actix, etc.

Regards, Peita

Let me know what you think. This obviously breaks some interfaces, I think the only real question is whether you want to return failure::Errors. Currently there's basically a roundtrip, since all the errors we wrap implement Fail.

cc #29

Hi,

I've made a PR that changes a couple of things to this library:

• I've added #![deny(missing_docs)] to the crate, and documented all public items in the crate,
• I've modified the macro that generates the setters for the Mail struct, so that it now correctly displays the provided documentation,
• I've added a From<(&str, &str)> impl to the destination struct, to more succinctly be able to constrIuct this type,
• I found a couple of use serde_json; occurrences, but they don't do anything since serde_json is a dependency, and thus always in scope,
• I added the native-tls feature, which is enabled by default, but that users can switch off when they use RusTLS if they don't want to link OpenSSL,
• I made the v2 api also switch to async reqwest when the async feature flag is enabled.

Let me know if I need to change anything!

I tried using this with the new change and it turns out life is really hard when you can't know WHY the status code is not a success, so here is a follow-up PR.

This is a start of the migration to the builder pattern for the V3 module. The V2 module should be considered deprecated since V3 has been out for years now and is the preferred way to send messages using SendGrid's API. Unless there is a strong objection, I will mark it as deprecated.

Closes #30 Closes #37 Closes #38

CC @Ten0 @otavio for review. The example has been updated to showcase the new API for now.

When updating a project to Rust 2018, a previously working sendgrid email setup returns a 415 StatusCode (Unsupported Media Type).

When using sendgrid-rs 0.7.2 the the V3Sender content-type header looks like...

headers.insert(
    header::CONTENT_TYPE,
    HeaderValue::from_static("application/x-www-form-urlencoded"),
);

However, the master branch has changed the content type to application/json which causes the emails to send correctly.

It looks like the master branch can be deployed as it is?

I need to access the message id returned by the v3 send API, but couldn't see a way to do it. Am I missing something?

To get something working in the meantime, I ended up making a branch that returns it instead of the response status, getting the value out of the X-Message-Id header. Is there some version of that change that would be worth me tidying up and opening as a PR?

The library provides lots of way to build Sendgrid queries that have zero chance to succeed: Examples:

sender.send(&Message::new())?;

sender.send(&Message::new()
			.set_from(self.from.clone())
			.set_subject(subject)
			.add_personalization(Personalization::new().add_to(Email::new().set_email(to_email)))
			.add_content(Content::new().set_value(body)))?;

sender.send(&Message::new()
			.set_subject(subject)
			.add_personalization(Personalization::new().add_to(Email::new().set_email(to_email)))
			.add_content(Content::new().set_content_type("text/html").set_value(body)))?;

sender.send(&Message::new()
			.set_from(self.from.clone())
			.add_personalization(Personalization::new().add_to(Email::new().set_email(to_email)))
			.add_content(Content::new().set_content_type("text/html").set_value(body)))?;

sender.send(&Message::new()
			.set_from(self.from.clone())
			.set_subject(subject)
			.add_content(Content::new().set_content_type("text/html").set_value(body)))?;

sender.send(&Message::new()
			.set_from(self.from.clone())
			.set_subject(subject)
			.add_personalization(Personalization::new().add_to(Email::new().set_email(to_email)))
			.add_content(Content::new().set_content_type("text/htlm").set_value(body)))?;

It's already been several times we've gotten trapped by this, resulting in broken deployed software.

Given the amount of fields that are mandatory/have restricted values, there should only be, as much as possible, constructors that respect the Sendgrid constraints.

e.g.:

sender.send(Message::new(
   "[email protected]",
   "[email protected]",
   Content::html("subject", "<strong>body</strong>"),
)

where Content could be:

#[serde(untagged)] // and flattened into the message
pub enum Content<'a> {
    SubjectAndBody {
        subject: &'a str,
        body: Body<'a>,
    }
    Template {
        // If I understand correctly https://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/index.html
        // specifying a template id makes subject and body optional
        template_id: &'a str,
        subject: Option<&'a str>,
        body: Option<Body<'a>>,
    }
}

pub struct Body<'a> {
    content_type: ContentType,
    body: &'a str,
}

pub enum ContentType {
    Html,
    PlainText,
}

etc.

I feel like providing typing for an API is be the whole point of this kind of library. Otherwise if I'm going to have to read the Sendgrid spec anyway to figure which fields are mandatory and where I should put them, I almost might as well write my own serde SDK.