Clever Geek Handbook

Is there something wrong with moving CLI / logical server side validation?

I have a client / server application. One of the clients is the CLI. The CLI does some basic validation and then makes SOAP requests to the server. The response is interpreted and the appropriate information is provided to the user. Each command included a request for a web service.

Every time the services change on the server side, a new CLI needs to be released.

I am wondering if there is something wrong with my incredible CLI subtlety. All it would do is send the command line to the server, where it will be checked, interpreted, and a response string returned.

(Even TAB completion can be done in collaboration with the server.)

I feel that in my case it will simplify development and reduce maintenance costs.

Are there any pitfalls that I am missing?

UPDATE

Scalability issues are not a high priority.

+1


source to share


4 answers


I think this is really just a matter of taste. The check has to happen somewhere; you are just trading complexity in your client with the same complexity in your software. This isn't necessarily bad for your architecture; you are really just providing an add-on service that gives subscribers an alternative means of accessing your existing services. The only thing I expected was code duplication; if you find that your CLI validation is doing the same things as some of your services (like parsing number) then refactoring to avoid duplication.



+1


source


in general, you'd be fine, but client side validation is a good way to reduce your workload if failed requests can be rejected earlier.



+1


source


I am wondering if there would be something wrong that would make my CLI incredibly thin.

...

I feel that in my case it will simplify development and reduce maintenance costs.

People have been doing this for years using telnet / SSH to remotely access the CLI that runs on the server. If all intelligence needs to be on the server anyway, there can be no reason your CLI would be a distributed client with intelligence. Just let it be a terminal session - if you manage to use SSH, what would I do - then the client part is executed once (or maybe just a ready-made bit of software) and all maintenance and updates happen on the server (welcome 1978 .).

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

+1


source


The use of name / value pairs in a query string is actually quite common. However, at this point, why bother with SOAP at all? Instead, just go for a RESTful architecture?

0


source






More articles:


All Articles