Anything wrong with moving CLI validation/logic server-side?

Question

I have a client/server application. One of the clients is a CLI. The CLI performs some basic validation then makes SOAP requests to a server. The response is interpreted and relevant information presented to the user. Every command involved a request to a web service.

Every time services are modified server-side, a new CLI needs to released.

What I'm wondering is if there would be anything wrong with making my CLI incredibly thin. All it would do is send the command string to the server where it would be validated, interpreted and a response string returned.

(Even TAB completion could be done with the server's cooperation.)

I feel in my case this would simplify development and reduce maintenance work.

Are there pitfalls I am overlooking?

UPDATE

Scalability issues are not a high priority.

Answer 1

in general, you'd be okay, but client-side validation is a good way to reduce your workload if bad requests can be rejected early.

Answer 2

Using name / value pairs in a request string is actually pretty prevalant. However, at that point, why bother with SOAP at all? Instead just move to a RESTful architecture?

Answer 3

I think this is really just a matter of taste. The validation has to happen somewhere; you're just trading off complexity in your client for the same amount of complexity in your software. That's not necessarily a bad thing for your architecture; you're really just providing an additional service that gives callers an alternate means of accessing your existing services. The only pitfall I'd look out for is code duplication; if you find that your CLI validation is doing the same things as some of your services (parsing numbers, for example), then refactor to avoid the duplication.

Answer 4

What I'm wondering is if there would be anything wrong with making my CLI incredibly thin.

...

I feel in my case this would simplify development and reduce maintenance work.

People have been doing this for years using telnet/SSH for remoting a CLI that runs on the server. If all the intelligence must be on the server anyway, there might be no reason to have your CLI be a distributed client with intelligence. Just have it be a terminal session - if you can get away with using SSH, that's what I'd do - then the client piece is done once (or possibly just an off-the-shelf bit of software) and all the maintenance and upgrades happen on the server (welcome to 1978).

Of course this only really applies if there really is no requirement for the client to be intelligent (which sounds like the case in your situation).