How to start creating an application API in .NET

Question

Hi,

In the company I work for we have a desktop application developed in .NET that we like to open up some parts for other software developers.

I see it like some kind of public methods that other software can access. Is there any standard approach, best practices or other experience of this?

I guess you could do this with Win32 calls, C/C++ programming etc. But I'm mainly a .NET developer and have some years of experience programmming in mainly VB.NET but also some C#. I hope finding a way to do this within .NET. But it should be accessible for software developed in other languages.

Best regards/ Magnus

Answer 1

Developing a public API depends greatly on the functionality of your program. If you want to expose an API that is accessible to other languages, XML web services is generally the way to do it. This may not be practical for a desktop-only application, however.

Answer 2

There are two ways to go about this. The first involves using the Plug In / Module pattern. Start here for that.

A second way is to simply expose your API logic through well documented assemblies.

The way you pick really boils down to how you want it implemented. For example, Adobe Photoshop uses the plug-in pattern to great extent. MS Office uses both plug-ins as well as provides an object interface for working with the application.

UPDATE: Objects in .Net assemblies can be exposed to be consumed by external applications simply by setting the objects scope to Public. This includes windows forms, business objects, enum's, etc.

Just think about it from the external developer's perspective. What information will they need to have in order to be successful at extending / controlling your product? Whatever that is, put it in the help file.

Also, make use of the auto-documentation features of .Net. This includes adding xml documentation the the IDE already knows how to read and display via intellisense. For example:

/// <summary>
/// Gets all active documents for the specified customer.
/// </summary>
/// <param name="customerId">The Id of the customer.</param>
/// <returns>A list of documents for this customer.</returns>
public static List<Document> GetDocuments(int customerId)
{
    //... do something ...
}

Answer 3

"Expose the application through a public API" is not a detailed requirement definition. Before designing anything, get detailed requirements.

For an API, I recommend that you start with the requirements, and then proceed to use cases. Since this is an API, you should actually write some code using the proposed API, to see how it feels to program it. The code you write should cover the use cases you start with. You might even write that code in unit tests, then create the API through test-driven development and refactoring.

But anyway, since use cases focus on how the user will use the software, they will help you focus on what parts of the software the user uses directly. One use case may use another; but if a user does not directly use a particular use case, then that is one that need not be exposed publicly.

Note that this also has helped me in the development of web services. The use cases directly accessed by the user become the operations to expose through the service. Any use case that the user does not directly invoke will remain hidden, as implementation.

Answer 4

Create an API class that exposes what functions you want people to have access to and Register it for COM interop project ->properties -> build -> Register for COM interop