Request.data can have either of a URI with query parameters or a form-urlencoded string. A single field having two different meaning depending on context is error-prone.

Also, the field actually has nothing to do with the OAuth authorization process. It was introduced just as a convenience and not all users require it, spending cost for unnecessary feature.

For these reasons, I'm planning to separate the query serialization from the Authorize-ation process and make Signer return a single "Authorization" header String. So, I'm going to change this:

extern crate oauth1_request as oauth;

let mut builder = oauth::Builder::new(client, oauth::HmacSha1);
builder.token(token);

let req = Foo { a: 1 };

let oauth::Request { authorization, data } = builder.post_form("https://example.com/", &req);
assert_eq!(data, "a=1");

let oauth::Request { authorization, data } = builder.get("https://example.com/", &req);
assert_eq!(data, "https://example.com/?a=1");

to something like this:

extern crate oauth1_request as oauth;
extern crate url;

let mut builder = oauth::Builder::new(client, oauth::HmacSha1);
builder.token(token);

let req = Foo { a: 1 };

let mut url: url::Url = "https://example.com/".parse().unwrap();

// N.B. we now call this method `post` instead of `post_form`
// since the method no longer generates a form-urlencoded string.
let authorization: String = builder.post("https://example.com/", &req);
let form = oauth::make_form_urlencoded(&req);
assert_eq!(form, "a=1");

let authorization: String = builder.get(&url, &req);
oauth::make_query(&req, url.query_pairs_mut());
assert_eq!(url.as_str(), "https://example.com/?a=1");

The concrete interface for oauth::make_{form_urlencoded,query} above is yet to be decided. There a few possibility for them, including:

1. Using another crate like serde_urlencoded

2. Make Signer generic over a "target" type. For example, Signer<Authorization> (where Authorization is a unit struct) would create an "Authorization" header string, and Signer<url::form_urlencoded::Serializer<_>> would append query pairs to the underlying Serializer, ignoring any OAuth parameters

While the term "token" in OAuth 1.0 refers to token credentials, oauth_credentials::Token represents a set of client credentials and token credentials, which are not identical concepts. The difference is confusing especially when a user uses the term to refer to the both concepts at the same time, which is the case almost every time they construct a Token.

let token: Credentials = get_token(&client).await; // Token credentials
let token = Token::new(client, token); // Client and token credentials

Also, token.client() and token.token() doesn't sound very well.

So I think Token should be renamed if there is a good alternative. Renaming a type doesn't prevent the semver trick, so it wouldn't cause a breakage provided that it is done before 1.0 release.

This may already be possible and I just haven't figured it out, but it would be very useful (for example for the evernote API https://dev.evernote.com/doc/articles/authentication.php) to be able to generate a uri + query string rather than an auth header for the purposes of fetching a token for APIs that expect the oauth params in this fashion. Seems like this is something the lib supports for regular requests but not token fetching?

I need to create a query string from, e.g.:

#[derive(oauth1_request::Request)]
struct TextQuery {
    r#type: String,
}

But oauth1_request::to_uri_query(uri, &request_query) produces ?r#type=text (note r#). With serde you would use #[serde(rename = "type")], but it's not clear how to best go about doing it here.