возврат нулевых значений из вызова веб-службы - PullRequest
4 голосов
/ 30 сентября 2008

У меня есть API веб-службы. Некоторые вызовы возвращают объекты, содержащие текстовые поля с информацией, предоставленной пользователем. Как с точки зрения дизайна, так и с точки зрения безопасности, каковы недостатки возврата пустых значений в этих полях, если информация не была предоставлена? Есть ли явное преимущество в том, что вместо этого всегда нужно возвращать пустую строку, а не упростить API, не требуя, чтобы клиентский код проверял наличие нулей?

Ответы [ 6 ]

1 голос
/ 22 сентября 2009

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

Сказав это, я столкнулся с проблемами, когда клиенты веб-служб, такие как Adobe Flex, не могут работать с пустыми значениями, и вам может потребоваться передать пустую строку, если клиент не может быть изменен.

В любом случае я не вижу проблем с безопасностью.

1 голос
/ 30 сентября 2008

Краткий ответ: Не используйте нуль в веб-сервисах.

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

До тех пор, пока я не определю значение для нуля, я предпочитаю возвращать пустую строку и использовать String.IsNUllOrEmpty на стороне обработки, потому что вместо любых будущих знаний я должен предполагать, что пустые и пустые значения совпадают.

Но у веб-сервисов есть особая особенность, заключающаяся в том, что в инструментах было допущено более чем значительная доля ошибок между различиями в <code><element/>, <code><element></element> и просто отсутствующим элементом , Достаточно путаницы, что, если я не контролирую все это, я не верю, что совместимость приемлема.

Так что, если у меня есть такое понятие, как нуль, которое я должен представлять, я создам отдельный логический элемент для указания наличия / отсутствия.

1 голос
/ 30 сентября 2008

Все зависит от того, считаете ли вы значение пустой строки семантически отличным от пустой строки.

Если пустая и пустая строки означают, что для этого поля нет данных, то я не вижу причин не упрощать жизнь клиента, не проверяя и не возвращая пустую строку.

0 голосов
/ 03 апреля 2019

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

private static ObjectMapper configureMapper(ObjectMapper mapper) {
  mapper.setDefaultPropertyInclusion(JsonInclude.Value.construct(JsonInclude.Include.NON_EMPY, JsonInclude.Include.NON_NULL));
  mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
  return mapper;
}
0 голосов
/ 30 сентября 2008

Ноль просто означает ноль. Там нет никаких проблем с безопасностью.

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

Таким образом, пустые строки или другие значения часового не спасают вас от проверки ввода, и они также не обязательно облегчают жизнь. Семантически пустые строки тоже не равны нулю, они пусты.

Что бы это ни стоило, xml, сгенерированный .net SoapFormatter для пустого значения, ничего не значит, и это не то же самое, что пустая строка. Это тривиальный пример, но информативный. Если вы отправляете null, вы также отправляете меньше данных, что может быть чем-то, что нужно учитывать.

{
    [WebMethod]
    public MyClass HelloWorld() 
    {
        MyClass val = new MyClass()
        {
            IsValid = false,
            HelloString = "Hello World",
            BlankString = "",
            Nested = new NestedClass { Name = "Bob" }
        };

        return val;
    }

}

public class MyClass
{
    public bool IsValid { get; set; }
    public string HelloString { get; set; }
    public string BlankString { get; set; }
    public string OtherString { get; set; }
    public NestedClass Nested { get; set; }
    public NestedClass NullNested { get; set; }
}

public class NestedClass
{
    public string Name { get; set; }
}

дает следующий ответ xml. Обратите внимание, что OtherString и NullNested полностью отсутствуют в ответе, что отличается от BlankString.

<MyClass>
  <IsValid>false</IsValid> 
  <HelloString>Hello World</HelloString> 
  <BlankString /> 
  <Nested>
    <Name>Bob</Name> 
  </Nested>
</MyClass>
0 голосов
/ 30 сентября 2008

Я не думаю, что существует проблема безопасности, связанная с возвратом нулевого значения по сравнению с возвращением пустой строки.

Нет реального недостатка в возврате нуля для тех полей, для которых нет информации - это то, что означают нули.

Вы можете упростить свой код клиента, используя

string.IsNullOrEmpty()

(при условии, что это .NET)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...