I have written some small HTTP services myself and the clients that consumed them. There's a question on CodeReview in the hot questions about a wrapper for some RESTful API which made me wonder, should one ever write such wrappers "by hand"?
My workflow was usually:
- Write server side code
- Test it or, to be honest, try it
- Write wrappers on the client side to use the service
I heard about languages that describe services (WSDL) and that they allow the automated generation of such wrappers. That makes sense: if the service changes, so do the wrappers.
I never used such service descriptions for the services I wrote. However, I noticed the duplicated effort of writing code both on server and client to a common "interface". There's also a lot of boilerplate code involved, like making requests, serializing/deserializing data into JSON, XML or whatever format is used. It would be nice to derive the wrapper code automatically.
It is mentioned that the description languages are meant to be written automatically themselves, derived from some service code already written.
Why is that? Why would I not start the process by writing a description of the service, so that I could then create wrappers for it on both the server and the client side automatically? Or at least create the classes/method stubs with already (de-)/serialized parameters, etc. Why is it necessary to write code, to derive a description from it to derive code from that. Or is my understanding of service descriptions just wrong? I'd like to improve my code by using service descriptions.
When I start a next project that does not have to apply to any existing code, isn't it the best idea to create the description first, to have some abstract definition of the whole thing and derive everything else from it?