REST HTTP коды состояния для неудачной проверки или неверного дубликата

Да, decimal предназначен именно для этого.

Однако помните, что диапазон десятичного типа меньше, чем двойной. Это двойное значение может иметь большее значение, но оно делает это, теряя точность. Или, как указано в MSDN:

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

blockquote>

Основное различие между decimal и double заключается в том, что decimal является фиксированной точкой и double - плавающая точка . Это означает, что десятичное значение сохраняет точное значение, а double представляет значение, представленное дробью, и является менее точным. A decimal - 128 бит, поэтому для сохранения требуется два места. Вычисления на decimal также медленнее (measure!).

Если вам нужна еще большая точность, тогда BigInteger можно использовать из .NET 4. (Вам нужно будет обрабатывать десятичные точки самостоятельно). Здесь вам следует знать, что BigInteger неизменен, поэтому любая арифметическая операция на нем создаст новый экземпляр - если числа большие, это может привести к искажению производительности.

Я предлагаю вам точно посмотреть, как точно вам нужно быть. Возможно, ваш алгоритм может работать с нормализованными значениями, которые могут быть меньше? Если производительность является проблемой, один из встроенных типов с плавающей запятой, вероятно, будет быстрее.

748
задан Raedwald 3 September 2014 в 15:02
поделиться

3 ответа

Сбой проверки ввода: 400 Bad Request + ваше необязательное описание. Это предложено в книге "RESTful Web Services". Для двойной отправки: 409 Conflict


Обновление июня 2014

Соответствующей спецификацией раньше был RFC2616, который давал использование 400 (Bad Request) довольно узко, как

Запрос не может быть понят сервером из-за неправильного синтаксиса

Поэтому можно было бы утверждать, что он не подходит для семантических ошибок. Но теперь нет; с июня 2014 года соответствующий стандарт RFC 7231, который заменяет предыдущий RFC2616, дает возможность использовать 400 (Bad Request) более широко как

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

742
ответ дан 22 November 2019 в 21:22
поделиться

Я рекомендую код состояния 422, «Необработанный объект» .

11.2. 422 Unprocessable Entity

Код состояния 422 (Unprocessable Entity) означает, что сервер понимает тип содержимого объекта запроса (следовательно, код состояния 415 (Unsupported Media Type) неприемлем), и синтаксис объекта запроса правильный ( таким образом, код состояния 400 (неверный запрос) не подходит), но не удалось обработать содержащиеся инструкции. Например, это состояние ошибки может возникнуть, если тело запроса XML содержит правильно сформированные (т. Е. Синтаксически правильные), но семантически ошибочные инструкции XML.

206
ответ дан 22 November 2019 в 21:22
поделиться
  • Неудачная проверка: 403 Forbidden ("Сервер понял запрос, но отказывается его выполнить"). Вопреки распространенному мнению, RFC2616 говорит не "403 предназначен только для неудачной аутентификации", а "403: Я знаю, чего вы хотите, но я не буду этого делать". Это условие может быть связано с аутентификацией, а может и не быть.
  • Попытка добавить дубликат: 409 Conflict ("Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.")

Вам определенно следует дать более подробное объяснение в заголовках и/или теле ответа (например, с помощью пользовательского заголовка - X-Status-Reason: Validation failed).

271
ответ дан 22 November 2019 в 21:22
поделиться
Другие вопросы по тегам:

Похожие вопросы: