Software Design & Web Service Design

Question

I'm about to design my Web service API, most of the functions of my API is basically very simular to my web application.

Now the question is, should I create 1 single method and reuse them for both the web application and the web service api? (This seems to be the logical solution, however its very complicated; it's much easier to duplicate the method used by the web application, and keep both separate, ie one method for the web application and one method for the web service.)

How do you guys do it?

1) REUSE: one main method and reuse them for both web application and web service application (I like this but it's complicated)

• WebAppMethodX --uses--> COMMONFUNCTIONMETHOD_X
• APIMethodX ---uses----> COMMONFUNCTIONMETHOD_X

ie Commonfunctionmethod_x contains reusable set of common features

PRO: less code, less maintenance, less bugs.

CON: very complicated

2) DUPLICATE: two methods, one method for the web application and one method for the web service.

• WebAppMethodX
• APIMethodX

PRO: simple

CON: duplication = more code, more maintenance, more bugs!

Answer 1

Your use case will very likely be different for your public webservice API than for your internal application API. Create a common service project / tier and use that same tier from both your web app and your public-facing webservice API. Create a separate http-invokable method for each of your web app and your webservice.

It comes down to there being

1) different security concerns. For instance, it is nice (often required) to provide a sample client application making use of your public API so that others can easily get up to speed with what you've provided. That client API may need to pass object constructs that you provide them that have been stripped of internal, secure logic/content. (Remember that compiled C# might as well be clear text with Reflector!)

2) different needs and constraints. For instance, for an internal application call you're going to sometimes enforce different business rules vs. your public facing webservice API (often with the latter being much more constrained to scope).

If you design your business logic into your service layer and invoke those classes/methods well from your web project and your webservice project respectively you're going to have a lot of code reuse anyway without trying to overcomplicate things by mixing use cases.