Что-то не так с перемещением проверки CLI / логики на стороне сервера?

Question

У меня есть клиент-серверное приложение. Одним из клиентов является CLI. CLI выполняет некоторую базовую проверку, а затем отправляет запросы SOAP на сервер. Ответ интерпретируется и соответствующая информация предоставляется пользователю. Каждая команда включала запрос к веб-сервису.

Каждый раз, когда службы модифицируются на стороне сервера, необходимо выпускать новый CLI.

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

(Даже завершение TAB может быть выполнено при взаимодействии с сервером.)

Я считаю, что в моем случае это упростит разработку и сократит объем работ по техническому обслуживанию.

Есть ли подводные камни, которые я пропускаю?

UPDATE

Проблемы масштабируемости не являются приоритетными.

Answer 1

Что меня интересует, так это то, что было бы неправильно делать мой CLI невероятно тонким.

...

Я считаю, что в моем случае это упростит разработку и сократит объем работ по техническому обслуживанию.

Люди годами занимались этим, используя telnet / SSH для удаленного управления интерфейсом командной строки, который работает на сервере. Если в любом случае все данные должны быть на сервере, может быть, нет причин для того, чтобы ваш CLI был распределенным клиентом с интеллектом. Просто пусть это будет терминальная сессия - если вы можете обойтись без использования SSH, это то, что я бы сделал - тогда клиентская часть выполняется один раз (или, возможно, просто готовый бит программного обеспечения) и все обслуживание и обновления происходят на сервере (добро пожаловать в 1978).

Конечно, это действительно применимо только в том случае, если клиенту не нужно быть умным (это похоже на ситуацию в вашей ситуации).

Answer 2

Я думаю, что это действительно вопрос вкуса. Проверка должна произойти где-то; вы просто обмениваете сложность в своем клиенте на то же количество сложности в своем программном обеспечении. Это не обязательно плохо для вашей архитектуры; вы на самом деле просто предоставляете дополнительную услугу, которая дает абонентам альтернативный способ доступа к вашим существующим услугам. Единственная ловушка, на которую я обращаю внимание, это дублирование кода; если вы обнаружите, что ваша проверка CLI выполняет те же действия, что и некоторые из ваших служб (например, при разборе чисел), то выполните рефакторинг, чтобы избежать дублирования.

Answer 3

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

Answer 4

Использование пар имя / значение в строке запроса на самом деле довольно распространено. Тем не менее, в этот момент зачем вообще работать с SOAP? Вместо этого просто перейти на RESTful архитектуру?