PostUrlEncodedAsync Flurl игнорирует имена JsonProperty - PullRequest
0 голосов
/ 31 января 2019

Я использую Flurl (один из моих любимых API), чтобы публиковать данные формы в URL.Я хорошо знаком с использованием атрибутов JsonProperty для именования ключей и использования стандартного корпуса для c #.

Но когда я использую PostUrlEncodedAsync, обычный код JsonProperty не преобразуется в «ключ», а остается «KeyName», и вызов не выполняется.

public class TokenTest
{
    [JsonProperty("key")]
    public string KeyName { get; set; }
}

Так что я немногосбит с толку, что это не работает прямо из коробки.

var request = new TokenTest
{
   KeyName = "ewr1-QuQ5jo88WfCpNPz2kTb8ES",
};

var result = await url.PostUrlEncodedAsync(request).ReceiveString();

Мой вызов не выполняется, так как ему нужен ключ, но я отправляю KeyName.Атрибуты JsonProperty / DataMember всегда работали в прошлом, так почему же здесь происходит сбой?


Поскольку я работаю над проблемой, кажется, что это происходит из-за того, что этот метод вызывает DefaultUrlEncodedSerializer, чтобы сделатьсериализация.Этот сериализатор игнорирует имена JsonProperty.

   var urlEncodedContent = new CapturedUrlEncodedContent(request.Settings.UrlEncodedSerializer.Serialize(token));
   var jsonEncodedContent = new CapturedUrlEncodedContent(request.Settings.JsonSerializer.Serialize(token));

Например, jsonEncodedContent использует атрибут JsonProperty, а urlEncodedContent игнорирует атрибут.

1 Ответ

0 голосов
/ 31 января 2019

JsonProperty, как следует из названия, относится к сериализации JSON.Это на самом деле функция Json.NET;тот факт, что он работает с Flurl, является лишь удобным следствием того факта, что Flurl использует Json.NET в своем сериализаторе JSON по умолчанию.Но я не думаю, что разумно ожидать, что что-то под названием JsonProperty будет работать с URL-кодировкой, потому что URL-кодирование не имеет ничего общего с JSON.

Вы можете обойти это довольно легко, просто проецируя наанонимный объект:

url.PostUrlEncodedAsync(new { key = token.KeyName });

Не такой чистый или безопасный для типов, но я всегда считал, что это приемлемо, поскольку данные в кодировке URL, как правило, меньше / плосче / проще, чем полезные данные JSON, в среднем.

...