Json ошибка 400

As a complementary, for those who might meet the same issue as mine, I’m using $.ajax to post form data to server and I also got the 400 error at first.

Assume I have a javascript variable,

var formData = {
    "name":"Gearon",
    "hobby":"Be different"
    }; 

Do not use variable formData directly as the value of key data like below:

$.ajax({
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: formData,
    success: function(data, textStatus){
        alert("Data: " + data + "\nStatus: " + status); 
    }
});

Instead, use JSON.stringify to encapsulate the formData as below:

$.ajax({
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: JSON.stringify(formData),
    success: function(data, textStatus){
        alert("Data: " + data + "\nStatus: " + status); 
    }
});

Anyway, as others have illustrated, the error is because the server could not recognize the request cause malformed syntax, I’m just raising a instance at practice. Hope it would be helpful to someone.

The following document provides reference information about the status codes
and error messages that are used in the Cloud Storage JSON API. For
the page specific to the Cloud Storage XML API, see
HTTP status and error codes for XML.

Error Response Format

Cloud Storage uses the standard HTTP error reporting format for the
JSON API. Successful requests return HTTP status codes in the 2xx range. Failed
requests return status codes in the 4xx and 5xx ranges. Requests that require a
redirect returns status codes in the 3xx range. Error responses usually include
a JSON document in the response body, which contains information about the
error.

The following examples show some common errors. Note that the header
information in the responses is omitted.

401 Unauthorized

{
"error": {
 "errors": [
  {
   "domain": "global",
   "reason": "required",
   "message": "Login Required",
   "locationType": "header",
   "location": "Authorization"
  }
 ],
 "code": 401,
 "message": "Login Required"
 }
}

403 Forbidden

{
 "error": {
  "errors": [
   {
    "domain": "global",
    "reason": "forbidden",
    "message": "Forbidden"
    }
  ],
  "code": 403,
  "message": "Forbidden"
 }
}

404 Not Found

{
"error": {
 "errors": [
  {
   "domain": "global",
   "reason": "notFound",
   "message": "Not Found"
  }
 ],
 "code": 404,
 "message": "Not Found"
 }
}

409 Conflict

{
"error": {
 "errors": [
  {
   "domain": "global",
   "reason": "conflict",
   "message": "You already own this bucket. Please select another name."
  }
 ],
 "code": 409,
 "message": "You already own this bucket. Please select another name."
 }
}

The following table describes the elements that can appear in the response body
of an error. Fields should be used together to help determine the problem.
Also, the example values given below are meant for illustration and are not an
exhaustive list of all possible values.

HTTP Status and Error Codes

This section provides a non-exhaustive list of HTTP status and error codes that
the Cloud Storage JSON API uses. The 1xx Informational and 2xx
Success codes are not discussed here. For more information, see Response Status
Codes in RFC 7231 §6, RFC 7232 §4,
RFC 7233 §4, RFC 7235 §3, and RFC 6585.

302—Found

303—See Other

304—Not Modified

307—Temporary Redirect

308—Resume Incomplete

400—Bad Request

401—Unauthorized

403—Forbidden

404—Not Found

405—Method Not Allowed

408—Request Timeout

409—Conflict

410—Gone

411—Length Required

412—Precondition Failed

413—Payload Too Large

416—Requested Range Not Satisfiable

429—Too Many Requests

499—Client Closed Request

500—Internal Server Error

502—Bad Gateway

This error is generated when there was difficulty reaching an internal service.
It is not formatted with a JSON document. You should retry the request
using truncated exponential backoff.

503—Service Unavailable

504—Gateway Timeout

This error is generated when there was difficulty reaching an internal service.
It is not formatted with a JSON document. You should retry the request
using truncated exponential backoff.

Уровень сложности
Сложный

Время на прочтение
12 мин

Количество просмотров 4.4K

Это главы 39 и 40 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Глава 39. Работа с ошибками в HTTP API

Рассмотренные в предыдущих главах примеры организации API согласно стандарту HTTP и принципам REST покрывают т.н. «happy path», т.е. стандартный процесс работы с API в отсутствие ошибок. Конечно, нам не менее интересен и обратный кейс — каким образом HTTP API следует работать с ошибками, и чем стандарт и архитектурные принципы могут нам в этом помочь. Пусть какой-то агент в системе (неважно, клиент или гейтвей) пытается создать новый заказ:

POST /v1/orders?user_id=<user_id> HTTP/1.1
Authorization: Bearer <token>
If-Match: <ревизия>

{ /* параметры заказа */ }

Какие потенциальные неприятности могут ожидать нас при выполнении этого запроса? Навскидку, это:

1. Запрос не может быть прочитан (недопустимые символы, нарушение синтаксиса).

2. Токен авторизации отсутствует.

3. Токен авторизации невалиден.

4. Токен валиден, но пользователь не обладает правами создавать новый заказ.

5. Пользователь удалён или деактивирован.

6. Идентификатор пользователя неверен (не существует).

7. Ревизия не передана.

8. Ревизия не совпадает с последней актуальной.

9. В теле запроса отсутствуют обязательные поля.

10. Какое-то из полей запроса имеет недопустимое значение.

11. Превышены лимиты на допустимое количество запросов.

12. Сервер перегружен и не может ответить в настоящий момент.

13. Неизвестная серверная ошибка (т.е. сервер сломан настолько, что диагностика ошибки невозможна).

Исходя из общих соображений, соблазнительной кажется идея назначить каждой из ошибок свой статус-код. Скажем, для ошибки (4) напрашивается код 403, а для ошибки (11) — 429. Не будем, однако, торопиться, и прежде зададим себе вопрос с какой целью мы хотим назначить тот или иной код ошибки.

В нашей системе в общем случае присутствуют три агента: пользователь приложения, само приложение (клиент) и сервер. Каждому из этих акторов необходимо понимать ответ на три вопроса относительно ошибки (причём для каждого из акторов ответ может быть разным):

1. Кто допустил ошибку (конечный пользователь, разработчик клиента, разработчик сервера или какой-то промежуточный агент, например, программист сетевого стека).

   • Не забудем учесть тот факт, что и конечный пользователь, и разработчик клиента могут допустить ошибку намеренно, например, пытаясь перебором подобрать пароль к чужому аккаунту.

2. Можно ли исправить ошибку, просто повторив запрос.

   • Если да, то через какое время.

3. Если повтором запроса ошибку исправить нельзя, то можно ли её исправить, переформулировав запрос.

4. Если ошибку вообще нельзя исправить, то что с этим делать.

На один из этих вопрос в рамках стандарта HTTP ответить достаточно легко: регулировать желаемое время повтора запроса можно через параметры кэширования ответа и заголовок Retry-After. Также HTTP частично помогает с первым вопросом: для определения, на чьей стороне произошла ошибка, используется первая цифра статус-кода (см. ниже).

Со всеми остальными вопросами, увы, ситуация сильно сложнее.

Клиентские ошибки

Статус-коды, начинающиеся с цифры 4, индицируют, что ошибка допущена пользователем или клиентом (или, по крайней мере, сервер так считает). Обычно, полученную 4xx повторять бессмысленно — если не предпринять дополнительных действий по изменению состояния сервиса, этот запрос не будет выполнен успешно никогда. Однако из этого правила есть исключения, самые важные из которых — 429 Too Many Requests и 404 Not Found. Последняя по стандарту имеет смысл «состояния неопределённости»: сервер имеет право использовать её, если не желает раскрывать причины ошибки. После получения ошибки 404, можно сделать повторный запрос, и он вполне может отработать успешно. Для индикации персистентной ошибки «ресурс не найден» используется отдельный статус 410 Gone.

Более интересный вопрос — а что всё-таки клиент может (или должен) сделать, получив такую ошибку. Как мы указывали в главе «Разграничение областей ответственности», если ошибка может быть исправлена программно, необходимо в машиночитаемом виде индицировать это клиенту; если ошибка не может быть исправлена, необходимо включить человекочитаемые сообщения для пользователя (даже просто «попробуйте начать сначала / перезагрузить приложение» лучше с точки зрения UX, чем «неизвестная ошибка») и для разработчика, который будет разбираться с проблемой.

С восстановимыми ошибками в HTTP, к сожалению, ситуация достаточно сложная. С одной стороны, протокол включает в себя множество специальных кодов, которые индицируют проблемы с использованием самого протокола — такие как 405 Method Not Allowed (данный глагол неприменим к указанному ресурсу), 406 Not Acceptable (сервер не может вернуть ответ согласно Accept-заголовкам запроса), 411 Length Required, 414 URI Too Long и так далее. Код клиента может обработать данные ошибки и даже, возможно, предпринять какие-то действия по их устранению (например, добавить заголовок Content-Length в запрос после получения ошибки 411), но все они очень плохо применимы к ошибкам в бизнес-логике. Например, мы можем вернуть 429 Too Many Requests при превышении лимитов запросов, но у нас нет никакого стандартного способа указать, какой именно лимит был превышен.

Частично проблему отсутствия стандартных подходов к возврату ошибок компенсируют использованием различных близких по смыслу статус-кодов для индикации разных состояний (либо и вовсе выбор произвольного кода ошибки и придания ему нового смысла в рамках конкретного API). В частности, сегодня де-факто стандартом является возврат кода 401 Unauthorized при отсутствии заголовков авторизации или невалидном токене (получение этого кода, таким образом, является сигналом для приложения предложить пользователю залогиниться в системе), что противоречит стандарту (который требует при возврате 401 обязательно указать заголовок WWW-Authenticate с описанием способа аутентификации пользователя; нам неизвестны реальные API, которые выполняют это требованием).

Однако таких кодов, которые могут отражать нюансы одной и той же проблемы, в стандарте очень мало. Фактически, мы приходим к тому, что множество различных ошибок в логике приложения приходится возвращать под очень небольшим набором статус-кодов:

• 400 Bad Request для всех ошибок валидации запроса (некоторые пуристы утверждают, что, вообще говоря, 400 соответствует нарушению формата запроса — невалидному JSON, например — а для логических ошибок следует использовать код 422 Unprocessable Content; в постановке задачи это мало что меняет);

• 403 Forbidden для любых проблем, связанных с авторизацией действий клиента;

• 404 Not Found в случае, если какие-то из указанных в запросе сущностей не найдены либо раскрытие причин ошибки нежелательно;

• 409 Conflict при нарушении целостности данных;

• 410 Gone если ресурс был удалён;

• 429 Too Many Requests при превышении лимитов.

Разработчики стандарта HTTP об этой проблеме вполне осведомлены, и отдельно отмечают, что для решения бизнес-сценариев необходимо передавать в метаданных либо теле ответа дополнительные данные для описания возникшей ситуации («the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition»), что (как и введение новых специальных кодов ошибок) противоречит самой идее унифицированного машиночитаемого формата ошибок. (Отметим, что отсутствие стандартов описания ошибок в бизнес-логике — одна из основных причин, по которым мы считаем разработку REST API как его описал Филдинг в манифесте 2008 года невозможной; клиент должен обладать априорным знанием о том, как работать с метаинформацией об ошибке, иначе он сможет восстанавливать своё состояние после ошибки только перезагрузкой.)

Дополнительно, у проблемы есть и третье измерение в виде серверного ПО мониторинга состояния системы, которое часто полагается на статус-коды ответов при построении графиков и уведомлений. Между тем, ошибки, скрывающиеся под одним статус кодом — например ввод неправильного пароля и истёкший срок жизни токена — могут быть очень разными по смыслу; повышенный фон первой ошибки может говорить о потенциальной попытке взлома путём перебора паролей, а второй — о потенциальных ошибках в новой версии приложения, которая может неверно кэшировать токены авторизации.

Всё это естественным образом подводит нас к следующему выводу: если мы хотим использовать ошибки для диагностики и (возможно) восстановления состояния клиента, нам необходимо добавить машиночитаемую метаинформацию о подвиде ошибки и, возможно, тело ошибки с указанием подробной информации о проблемах — например, как мы предлагали в главе «Описание конечных интерфейсов»:

POST /v1/coffee-machines/search HTTP/1.1

{
  "recipes": ["lngo"],
  "position": {
    "latitude": 110,
    "longitude": 55
  }
}
→
HTTP/1.1 400 Bad Request
X-OurCoffeeAPI-Error-Kind:⮠
  wrong_parameter_value

{
  "reason": "wrong_parameter_value",
  "localized_message":
    "Что-то пошло не так.⮠
    Обратитесь к разработчику приложения.",
  "details": {
    "checks_failed": [{
      "field": "recipe",
      "error_type": "wrong_value",
      "message":
        "Value 'lngo' unknown.⮠
        Did you mean 'lungo'?"
    }, {
      "field": "position.latitude",
      "error_type": "constraint_violation",
      "constraints": {
        "min": -90,
        "max": 90
      },
      "message":
        "'position.latitude' value⮠
        must fall within⮠
        the [-90, 90] interval"
    }]
  }
}

Также напомним, что любые неизвестные 4xx-статус-коды клиент должен трактовать как ошибку 400 Bad Request, следовательно, формат (мета)данных ошибки 400 должен быть максимально общим.

Серверные ошибки

Ошибки 5xx индицируют, что клиент, со своей стороны, выполнил запрос правильно, и проблема заключается в сервере. Для клиента, по большому счёту, важно только то, имеет ли смысл повторять запрос и, если да, то через какое время. Если учесть, что в любых публично доступных API причины серверных ошибок, как правило, не раскрывают — в абсолютном большинстве кодов 500 Internal Server Error и 503 Service Unavailable достаточно для индикации серверных ошибок (второй код указывает, что отказ в обслуживании имеет разовый характер и есть смысл автоматически повторить запрос), или можно вовсе ограничиться одним из них с опциональным заголовком Retry-After.

Для внутренних систем, вообще говоря, такое рассуждение неверно. Для построения правильных мониторингов и системы оповещений необходимо, чтобы серверные ошибки, точно так же, как и клиентские, содержали подтип ошибки в машиночитаемом виде. Здесь по-прежнему применимы те же подходы — использование широкой номенклатуры кодов и/или передача типа ошибки заголовком — однако эта информация должна быть вырезана гейтвеем на границе внешней и внутренней систем, и заменена на общую информацию для разработчика и для конечного пользователя системы с описанием действий, которые необходимо выполнить при получении ошибки.

POST /v1/orders/?user_id=<user id> HTTP/1.1
If-Match: <ревизия>

{ parameters }
→
// Ответ, полученный гейтвеем
// от сервиса обработки заказов,
// метаданные которого будут
// использованы для мониторинга
HTTP/1.1 500 Internal Server Error
// Тип ошибки: получен таймаут от БД
X-OurCoffeAPI-Error-Kind: db_timeout
{ /* Дополнительные данные, например,
     какой хост ответил таймаутом */ }

// Ответ, передаваемый клиенту.
// Детали серверной ошибки удалены
// и заменены на инструкцию клиенту.
// Поскольку гейтвей не знает, был
// ли в действительности сделан заказ,
// клиенту рекомендуется попробовать
// повторить запрос и/или попытаться
// получить актуальное состояние
HTTP/1.1 500 Internal Server Error
Retry-After: 5

{ 
  "reason": "internal_server_error",
  "localized_message": "Не удалось⮠
    получить ответ от сервера.⮠
    Попробуйте повторить операцию
    или обновить страницу.",
  "details": {
    "can_be_retried": true,
    "is_operation_failed": "unknown"
  }
}

Вот здесь мы, однако, вступаем на очень скользкую территорию. Современная практика реализации HTTP-клиентов такова, что безусловно повторяются только немодифицирующие (GET, HEAD, OPTIONS) запросы. В случае модифицирующих запросов разработчик должен написать код, который повторит запрос — и для этого разработчику нужно очень внимательно прочитать документацию к API, чтобы убедиться, что это поведение допустимо и не приведёт к побочным эффектам.

Теоретически идемпотентные методы PUT и DELETE можно вызывать повторно. Практически, однако, ввиду того, что многие разработчики упускают требование идемпотентности этих методов, фреймворки работы с HTTP API по умолчанию перезапросов модифицирующих методов, как правило, не делают, но некоторую выгоду из следования стандарту мы всё же можем извлечь — по крайней мере, сама сигнатура индицирует, что запрос можно повторять.

Что касается более сложных ситуаций, когда мы хотим указать разработчику, что он может безопасно повторить потенциально неидемпотентную операцию, то мы могли бы предложить формат описания доступных действий в теле ошибки… но практически никто не ожидает найти такое описание в самой ошибке. Возможно, потому, что с ошибками 5xx, в отличие от 4xx, программисты практически не сталкиваются при написании клиентского кода, и мало какие тестовые среды позволяют такие ошибки эмулировать. Так или иначе, описывать необходимые действия при получении серверной ошибки вам придётся в документации. (Имейте в виду, что эти инструкции с большой долей вероятности будут проигнорированы. Таков путь.)

Организация системы ошибок в HTTP API на практике

Как понятно из вышесказанного, фактически есть три способа работать с ошибками HTTP API:

1. Расширительно трактовать номенклатуру статус-кодов и использовать новый код каждый раз, когда требуется индицировать новый вид ошибки. (Автор этой книги неоднократно встречал ситуации, когда при разработке API просто выбирался «похоже выглядящий» статус безо всякой оглядки на его описание в стандарте.)

2. Полностью отказаться от использования статус-кодов и вкладывать описание ошибки в тело и/или метаданные ответа с кодом 200. Этим путём идут почти все RPC-фреймворки.

   • 2а. Вариантом этой стратегии можно считать использование всего двух статус-кодов ошибок (400 для любой клиентской ошибки, 500 для любой серверной), опционально трёх (те же плюс 404 для статуса неопределённости).

3. Применить смешанный подход, то есть использовать статус-код согласно его семантике для индикации рода ошибки и вложенные (мета)данные в специально разработанном формате для детализации (подобно фрагментам кода, предложенным нами в настоящей главе).

Как нетрудно заметить, считать соответствующим стандарту можно только подход (3). Будем честны и скажем, что выгоды следования ему, особенно по сравнению с вариантом (2а), не очень велики и состоят в основном в чуть лучшей читабельности логов и большей прозрачности для промежуточных прокси.

Глава 40. Заключительные положения и общие рекомендации 

Подведём итог описанному в предыдущих главах. Чтобы разработать качественный HTTP API, необходимо:

1. Описать happy path, т.е. составить диаграмму вызовов для стандартного цикла работы клиентского приложения.

2. Определить каждый вызов как операцию над некоторым ресурсом и, таким образом, составить номенклатуру URL и применимых методов.

3. Понять, какие ошибки возможны при выполнении операций и каким образом клиент должен восстанавливаться из какого состояния.

4. Решить, какая функциональность будет передана на уровень протокола HTTP [какие стандартные возможности протокола будут использованы в сопряжении с какими инструментами разработки] и в каком объёме.

5. Опираясь на решения 1-4, разработать конкретную спецификацию.

6. Проверить себя: пройти по пунктам 1-3, написать псевдокод бизнес-логики приложения согласно разработанной спецификации, и оценить, насколько удобным, понятным и читабельным оказался результирующий API.

Позволим себе так же дать несколько советов по code style:

1. Не различайте пути с / на конце и без него и примите какую-то рекомендацию по умолчанию (мы рекомендуем все пути заканчивать на / — по простой причине, это позволяет разумно описать обращение к корню домена как ГЛАГОЛ /). Если вы решили запретить один из вариантов (скажем, пути без слэша в конце), при обращении по второму варианту должен быть или редирект или однозначно читаемая ошибка.

2. Включайте в ответы стандартные заголовки — Date, Content-Type, Content-Encoding, Content-Length, Cache-Control, Retry-After — и вообще старайтесь не полагаться на то, что клиент правильно догадывается о параметрах протокола по умолчанию.

3. Поддержите метод OPTIONS и протокол CORS на случай, если ваш API захотят использовать из браузеров.

4. Определитесь с правилами выбора кейсинга параметров (и преобразований кейсинга при перемещении параметра между различными частями запроса) и придерживайтесь их.

5. Всегда оставляйте себе возможность обратно-совместимого расширения операции API. В частности, всегда возвращайте корневой JSON-объект в ответах эндпойтов — потому что приписать новые поля к объекту вы можете, а к массивам и примитивам — нет.

   • Отметим также, что пустая строка не является валидным JSON, поэтому корректнее возвращать пустой объект {} там, где ответа не подразумевается (или статус 204 No Content с пустым телом, но тогда эндпойнт нельзя будет расширить в будущем).

6. Для всех GET-запросов указывайте политику кэширования (иначе всегда есть шанс, что клиент или промежуточный агент придумает её за вас).

7. Не эксплуатируйте известные возможности оперировать запросами в нарушение стандарта и не изобретайте свои решения для «серых зон» протокола. В частности:

   • не размещайте модифицирующие операции за методом GET и неидемпотентные операции за PUT / DELETE;

   • соблюдайте симметрию GET / PUT / DELETE методов;

   • не позволяйте GET / HEAD / DELETE-запросам иметь тело, не возвращайте тело в ответе метода HEAD или совместно со статус-кодом 204 No Content;

   • не придумывайте свой стандарт для передачи массивов и вложенных объектов в query — лучше воспользоваться HTTP-глаголом, позволяющим запросу иметь тело, или, в крайнем случае, передать параметры в виде Base64-кодированного JSON-поля;

   • не размещайте в пути и домене URL параметры, по формату требующие эскейпинга (т.е. могущие содержать символы, отличные от цифр и букв латинского алфавита); для этой цели лучше воспользоваться query-параметрами или телом запроса.

8. Ознакомьтесь хотя бы с основными видами уязвимостей в типичных имплементациях HTTP API, которыми могут воспользоваться злоумышленники:

   • CSFR

   • SSRF

   • HTTP Response Splitting

   • Unvalidated Redirects and Forwards

   и заложите защиту от этих векторов атак на уровне вашего серверного ПО. Организация OWASP предоставляет хороший обзор лучших security-практик для HTTP API.

В заключение хотелось бы сказать следующее: HTTP API — это способ организовать ваше API так, чтобы полагаться на понимание семантики операций как разнообразным программным обеспечением, от клиентских фреймворков до серверных гейтвеев, так и разработчиком, который читает спецификацию. В этом смысле экосистема HTTP предоставляет пожалуй что наиболее широкий (и в плане глубины, и в плане распространённости) по сравнению с другими технологиями словарь для описания самых разнообразных ситуаций, возникающих во время работы клиент-серверных приложений. Разумеется, эта технология не лишена своих недостатков, но для разработчика публичного API она является выбором по умолчанию — на сегодняшний день скорее надо обосновывать отказ от HTTP API чем выбор в его пользу.

I have been trying to get this to work for the last couple of days, I have a metro app that needs to get and post json data to a wcf service. The getting the json data from wcf was easy enough however I have encountered 400 Bad Request error when I try to
post parsed json data. Below is my code, hopefully someone has had this problem and can help me out.

Service1.svc.cs

public string InsertSale(string saleDetails)
        {
            return "";
        }

IService.cs

[WebInvoke(Method = "POST", UriTemplate = "SubmitSale", ResponseFormat = WebMessageFormat.Json, RequestFormat = WebMessageFormat.Json)]
[OperationContract]
string InsertSale(string saleDetails);

MainPage.xaml.cs

private async void PostToJsonServer(SalesDetails sd)
        {
            string postBody = JsonConvert.SerializeObject(sd);
//below is a sample of postBody after Serialization

            HttpClient client = new HttpClient();
            HttpContent content = new StringContent(postBody, Encoding.UTF8, "application/json");
            Uri postUrl = new Uri("http://localhost:1325/Service1.svc/JSONService/SubmitSale", UriKind.Absolute);

            content.Headers.ContentType = new MediaTypeHeaderValue("application/json");
            client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

            HttpResponseMessage wcfResponse = await client.PostAsync(postUrl, content);

            MessageDialog md = new MessageDialog(wcfResponse.ToString() + "\r\n\r\n\r\n" + wcfResponse.Content.ToString(), "MESSGAE");
            md.ShowAsync();
        }

SalesDetails Data Contract

[DataContract]
    public class SalesDetails
    {
        string saleID = string.Empty;
        string saleType = string.Empty;
        double saleTotal = 0.0;
        double saleTax = 0.0;
        string saleStatus = string.Empty;
        int storeID = 0;
        DateTime dateTime = DateTime.Now;
        List<SalesProductDetails> saleProducts = null;
        List<SalesPaymentDetails> payment = null;

        [DataMember]
        public string SaleID
        {
            get { return saleID; }
            set { saleID = value; }
        }

        [DataMember]
        public string SaleType
        {
            get { return saleType; }
            set { saleType = value; }
        }

        [DataMember]
        public double SaleTotal
        {
            get { return saleTotal; }
            set { saleTotal = value; }
        }

        [DataMember]
        public double SaleTax
        {
            get { return saleTax; }
            set { saleTax = value; }
        }

        [DataMember]
        public string SaleStatus
        {
            get { return saleStatus; }
            set { saleStatus = value; }
        }

        [DataMember]
        public string Username
        {
            get;
            set;
        }

        [DataMember]
        public int StoreInformation
        {
            get { return storeID; }
            set { storeID = value; }
        }

        [DataMember]
        public int CustomerID
        {
            get;
            set;
        }

        [DataMember]
        public int NumberOfCustomers
        {
            get;
            set;
        }

        [DataMember]
        public List<SalesProductDetails> Products
        {
            get { return saleProducts; }
            set { saleProducts = value; }
        }

        [DataMember]
        public List<SalesPaymentDetails> Payments
        {
            get { return payment; }
            set { payment = value; }
        }

        [DataMember]
        public DateTime DateTime
        {
            get { return dateTime; }
            set { dateTime = value; }
        }
    }

postBody Serialization example

{"SaleID":"","SaleType":"SAL","SaleTotal":9.0,"SaleTax":0.81818181818181812,"SaleStatus":"Paid","Username":"ben.ringrose","StoreInformation":1,"CustomerID":0,"NumberOfCustomers":1,"Products":[{"SaleID":"","SaleDetailsID":0,"ProductPrice":2.5,"ProductQty":1.0,"TaxAmount":0.22727272727272727,"ProductCode":"2182","ProductDescription":"TEA SMALL"},{"SaleID":"","SaleDetailsID":0,"ProductPrice":3.0,"ProductQty":1.0,"TaxAmount":0.27272727272727271,"ProductCode":"2183","ProductDescription":"TEA MEDIUM"},{"SaleID":"","SaleDetailsID":0,"ProductPrice":3.5,"ProductQty":1.0,"TaxAmount":0.31818181818181818,"ProductCode":"2184","ProductDescription":"TEA LARGE"}],"Payments":[{"SaleID":"","SalePaymentID":0,"PaymentName":"Cash","PaymentAmount":9.0}],"DateTime":"2015-05-06T11:26:07.2824181+10:00"}

Entire web.config file

<?xml version="1.0"?>
<configuration>

  <appSettings>
    <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />
  </appSettings>
  
  <system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5"/>
  </system.web>
  
  <system.serviceModel>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />

    <services>
      <service behaviorConfiguration="Default" name="WcfServiceTestingAndTagging.Service1">
        <!--<host>
          <baseAddresses>
            <add baseAddress = "http://10.18.4.200:8733/Service1/" />
            <add baseAddress = "http://10.18.4.200/CafePOS/" />
            <add baseAddress = "http://localhost:8733/Design_Time_Addresses/WcfServiceLibrary1/Service1/" />
          </baseAddresses>
        </host>-->

        <endpoint address="" binding="basicHttpBinding" contract="WcfServiceTestingAndTagging.IService1" />
        <endpoint address="JSONService" behaviorConfiguration="webBehavior" binding="webHttpBinding" contract="WcfServiceTestingAndTagging.IService1" />
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
    </services>
    
    <client>
      <endpoint address="" behaviorConfiguration="webBehavior" binding="webHttpBinding" contract="WcfServiceTestingAndTagging.IService1" />
      <endpoint address="basic" binding="basicHttpBinding" contract="WcfServiceTestingAndTagging.IService1" />
      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
    </client>
    
    <bindings>
      <basicHttpBinding>
        <binding name="BasicBinding" maxReceivedMessageSize="2000000" maxBufferSize="2000000" transferMode="Streamed">
          <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
        </binding>
      </basicHttpBinding>
    </bindings>

    <behaviors>
      <endpointBehaviors>
        <behavior name="webBehavior">
          <webHttp helpEnabled="true"/>
          <dataContractSerializer maxItemsInObjectGraph="100000000"/>
        </behavior>
      </endpointBehaviors>
      <serviceBehaviors>
        <behavior name="Default">
          <serviceMetadata httpGetEnabled="true" httpsGetEnabled="True" />
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
        <behavior name="">
          <serviceMetadata httpGetEnabled="True" httpsGetEnabled="True"/>
          <serviceDebug includeExceptionDetailInFaults="False" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    
    <protocolMapping>
      <add binding="basicHttpsBinding" scheme="https" />
    </protocolMapping>
    
  </system.serviceModel>
  
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
    <directoryBrowse enabled="true"/>
  </system.webServer>

</configuration>

If you need any other code please let me know and I will supply

Again I hope someone can help

Cheers,
Ben

Postman – один из самых популярных инструментов в области тестирования API. Он предоставляет широкий функционал, который позволяет настраивать запросы и контролировать получаемые ответы, а также проверять работу различных HTTP-методов, кодов состояния HTTP, кукисов и других важных аспектов. Однако, иногда встречаются ошибки, которые могут сбить с толку начинающих разработчиков. Один из самых распространенных видов ошибок – это «400 Bad Request». В данной статье мы рассмотрим, что такое данная ошибка, и как ее можно избежать.

Итак, что же такое «400 Bad Request»? Эта ошибка возникает, когда клиент отправляет запрос на сервер, который сервер не в состоянии обработать. В основном, ошибка 400 связана с тем, что передаваемые параметры не соответствуют требованиям сервера. Есть несколько причин возникновения этой ошибки, которые мы рассмотрим подробно ниже.

Неправильная структура JSON-документа

JSON-документ является форматом передачи данных, который используется в RESTful API. Неправильная структура этого документа может привести к ошибке «400 Bad Request». Например, если вы используете POST-запрос для отправки данных на сервер, но вами была отправлена неправильная структура JSON-документа, то сервер не сможет получить и обработать эти данные. В таких случаях, вам необходимо внимательно проверить структуру JSON-документа, чтобы убедиться, что он соответствует требованиям сервера.

Неправильный формат параметров

Если вы отправляете параметры в виде строки или числа, а сервер ожидает массив или объект, то вы получите ошибку «400 Bad Request». Например, если ваш сервер ожидает массив значений для параметра «ids», а вы отправляете его в виде строки, то сервер не сможет обработать этот запрос. В этом случае необходимо внимательно прочитать документацию вашего API и убедиться, что параметры, которые вы отправляете, соответствуют его требованиям.

Отсутствие обязательных данных

Некоторые API требуют определенных данных для выполнения запроса. Если вы не передали какие-то из этих данных, то сервер не сможет выполнить запрос. Например, если ваш API требует передачи авторизационных данных для запроса, то если вы их не передали, вы получите ошибку «400 Bad Request». В данном случае, вам следует убедиться, что вы передаете все необходимые параметры в запросе.

Ограничения на количество запросов

Некоторые API устанавливают ограничения на количество запросов, которые могут быть выполнены в течение определенного периода времени. Если вы отправляете запросы слишком быстро или превышаете установленные лимиты, то сервер может вернуть ошибку «400 Bad Request». В этом случае вам следует выяснить ограничения, установленные API, и привести количество ваших запросов в соответствие с ними.

В заключение, ошибки «400 Bad Request» в Postman могут возникать по многим причинам, таким как неправильный формат JSON-документа, отсутствие обязательных данных, использование неправильного типа параметров или превышение установленных лимитов запросов. Если вы столкнулись с этой ошибкой, а вы не знаете, как ее решить, следует внимательно прочитать документацию вашего API или связаться с его разработчиками. Также, вы можете использовать средства Postman для тестирования и отладки API-запросов, чтобы убедиться, что они корректно работают и исправно выполняют все требования сервера.