Любая помощь будет оценена
У меня есть общий класс, который облегчает вызовы WebAPI, он существует довольно давно и не вызывает проблем. Сегодня я получаю сообщение об ошибке и не знаю, где отследить проблему. точная ошибка
{"Unexpected character encountered while parsing value: [. Path 'PayLoad', line 1, position 12."}
то, что я получаю в ответ в результате звонка,
"{\"PayLoad\":[\"file_upload_null20180629155922²AAGUWVP2XUezeM3CiEnSOw.pdf\"],\"Success\":true,\"Message\":\"1 File(s) Uploaded\",\"Exceptions\":[]}"
Что выглядит правильно, и это то, что я ожидаю от обращения в службу поддержки.
Вот метод, который я вызываю, который внезапно перестает работать и не работает в последней строке
public static TR WebApiPost(string serveraddress, string endpoint, object data)
{
HttpResponseMessage msg;
var clienthandler = new HttpClientHandler
{
UseDefaultCredentials = false,
Credentials = new NetworkCredential(user, password, domain)
};
using (var client = new HttpClient(clienthandler) { BaseAddress = new Uri(serveraddress) })
{
client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
msg = client.PostAsync(endpoint, new StringContent(new JavaScriptSerializer().Serialize(data), Encoding.UTF8, "application/json")).Result;
}
var result = msg.Content.ReadAsStringAsync().Result;
return JsonConvert.DeserializeObject<TR>(result);
}
И, наконец, строка, которая действительно делает вызов (что не имеет значения)
returned = CallHelper<ResultStatus<string>>.WebApiPost(serviceurl, sendFileUrl, model);
Непонятно, откуда ваша веб-служба получает значение PayLoad, поэтому вполне возможно, что значение имеет метку порядка байтов (BOM) в начале. Это особенно актуально, если вы возвращаете содержимое файла в кодировке Unicode. Имейте в виду, что спецификация НЕ отображается, когда вы просматриваете строку в отладчике.
В своем веб-сервисе убедитесь, что вы не возвращаете спецификацию в значении PayLoad. Проверьте эту последовательность байтов в начале строки:
0xEF,0xBB,0xBF
Для получения дополнительной информации о метке порядка байтов: https://en.wikipedia.org/wiki/Byte_order_mark
Вот результат вызова службы перед десериализацией "{\" PayLoad \ ": [\" file_upload_null20180629155922²AAGUWVP2XUez eM3CiEnSOw.pdf \ "], \" Success \ ": true, \" Mes sage \ ": \ "1 файл (а) загружен \", \ "Исключения \": []} "
Я не верю, что что-либо в аспектах вашей настройки, упомянутых в ваших комментариях, неверно - я имею в виду потенциальную проблему со строкой в массиве PayLoad, в частности file_upload_null20180629155922²AAGUWVP2XUezeM3CiEnSOw.pdf. Это выглядит невинно, но если строка содержит спецификацию (которую вы не сможете увидеть; вам нужно проверить байты, составляющие строку), вы можете столкнуться с проблемами синтаксического анализа. Попробуйте сделать так, чтобы ваша конечная точка просто возвращала "foobar" в полезной нагрузке, если она работает, у вас проблема с спецификацией ...
Все мои вызовы возвращают объект, называемый ResultStatus, который имеет несколько свойств Success (bool, это сработало), Message (строка OK или сводка проблемы), Exceptions {список строк, содержащих подробную информацию об одной или нескольких проблемах) и необязательный PayLoad of введите TR, в этом случае полезная нагрузка является строкой. ResultStatus <string> означает, что полезная нагрузка является строкой.