Continuing another Q & A
From building web service APIs that support multiple message schemasI wrote earlier about a technique to build a web service with minimal endpoints that support multiple schemas (http://www.srtsolutions.com/blogs/billwagner/2005/05/03/id91025.aspx).
I received a question about the technique:
"
The benefit is obvious - plugable extension of a running service.
One question still remains - how do you tell the consumers of the service what request produces what response. The only way I see is type naming convention where there is a unique pair per "operation". This may result in a slight type bloat as now type reuse is not possible.
"
It turns out that this is not as much of an issue as it first appears. Yes, it does add more types. However, there is a one-to-one correspondance between request types and response types. That means it's a very simple matter to produce a layer of code that isolates this issue from all user's of your type.
Furthermore, where this technique really enhances web service maintainabilty over time is when you modify a request / response pair over time. Updated clients send the updated request, and receive the updated response. Older clients send the older request (which should still be valid at the server), and ignore any additions in the updated response.
I'm not necessarily advocating that every webservive have one endpoint. Rather, that this technique does provide an elegant way to update a web service over time.