2016-12-19 95 views
0

Я тестировал ответ службы, (тот же сервис, что и другие параметры).Существует ли принцип, который требует такого типа согласованности в результатах запроса?

При поиске по дате рождения один из возвращенных результатов был, скажем, идентификатором клиента = «CID1234».

Так что я снова искал, но на этот раз клиент id = «CID1234», тот же самый сервис, но это не дало результата.

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

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

Я включаю SQL-тег, потому что я точно знаю, что это был запрос sql, тогда этой ситуации не было бы, но я не знаю, почему, только что мы всегда воспринимали это как должное с SQL, может ли SOA быть другим ?

+0

Вы должны быть более конкретными. Похоже, вы используете строки, такие как '' CID1234''. Или вы имеете в виду, что поле 'CID' содержит целое значение' 1234'? И если вы используете строки, будьте осторожны с пробелами; следующие значения - это не то же самое ... '' CID1234'', ''CID 1234'','' CID1234 '' – MatBailie

ответ

0

Как dba я бы назвал недостатком бизнес-логики. Однако это действительно зависит от того, как разработчик должен использовать API.

Это может быть просто упущено или может быть преднамеренным для конфиденциальности или соображений безопасности. Или просто просто не требовалось.

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

Просто потому, что вы думаете, что он может или должен работать по-другому или лучше, не делает это неправильно.

+0

Давайте скажем, если бы это было на уровне базы данных, и прямые SQL-карьеры вели себя следующим образом, тогда это было бы рассмотрено ошибка, вопрос в том, почему это ошибка? какое требование лямбда-исчисления нарушено – Arjang

0

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

Это говорит, вы можете получить в такую ​​ситуацию, когда счет был активен в момент запроса 1 и стал неактивным в момент запроса 2. хотя я бы ожидать результат от запроса-говоря счет неактивен

+0

Нет, это не о сроках, если запись добывается по значению ее полей, тогда она извлекается, если iti добывается по значению какого-либо другого поля, тогда он не извлекается, бизнес-решение сделать вещи непоследовательными, не является допустимым оправданием. Либо запись активна, либо может быть доступна любым из ее значений полей или она неактивна и не может быть получена ни одним из значений полей. Это непоследовательное неприемлемое поведение. – Arjang

+0

Я говорю, что бизнес-решение так или иначе (т. Е. Либо вы не показываете неактивность, либо вы это делаете) Я согласен, что API должен быть последовательным –

 Смежные вопросы

  • Нет связанных вопросов^_^