tags:

views:

443

answers:

6

Hi,

I'll write a application but I've never experienced to allow people to use my application programming interface before.I mean how kinda design I should make to let people use my methods from outside world like API.

Please some one show me a way.I am kinda new to this.

+2  A: 

Make your methods you want to expose to the outside world public.

McWafflestix
Funny, McWafflestix. (You were trying to be funny, weren't you?)
Robert Harvey
Ok bro, I appreciated your effort to answer but I am saying I am new to this thing :)
Braveyard
@atarikg, I hope you know what the public keyword means. If you don't, you've got a long road ahead.
Robert Harvey
@RobertHarvey: Yeah, his response means I'm not entirely sure I was trying to be funny... :-)
McWafflestix
I know what it means, but I think writing API is more than that.
Braveyard
Well, atarikg, McWafflestix is right about one thing. The properties and methods that you mark public ARE the API. Everything else is best practices, and Mike's (new and improved) post pretty much covers that.
Robert Harvey
+5  A: 

It may not be the funniest reading, and certainly not the only reading to do on the subject, but while designing your class library (your API), do check in with the Design Guidelines for Developing Class Libraries every now and then, it's a good idea to have a design that corresponds a bit with the .NET Framework iteself.

Fredrik Mörk
+1  A: 

If you want to see what's new in this area, check out the Managed Extensibility Framework. It's a new/"unified (see the comments...)" method for exposing features for add-ins and other extensibility/modularity.

280Z28
Cmn! Why this common? Do you thik that users that already use IoC or other composition solutions would like to have dependency on yet another solution? API should be IoC agnostic. Wait I will add this to my answer.
Mike Chaliy
Are you happy now that I changed "common" to "unified"? I was just pointing out its existence and what they are intending it for. Plus it has some neat concepts that at least make it work perusing.
280Z28
Well, few months ago, I have had opportunity to integrate into our Windsor based application component based on MEF. I ended with implementing my own abstractions over this component. I think public API should provide independent API. Plain interfaces are the best. Everything including MEF supports them. Makes sence?
Mike Chaliy
+1  A: 

I found this presentation to be particularly insightful:

How to Design a Good API and Why it Matters
http://lcsd05.cs.tamu.edu/slides/keynote.pdf

Robert Harvey
Thanks, but actually first I wanna learn how to design basic API,instead of designing good API :)
Braveyard
+6  A: 
  1. Expose as little as you can. Every bit you publish, will return to you x100 in next version. Keeping compatibility is very hard.
  2. Create abstractions for everything you publish. You will definitely change your internals, but your existing users should stay compatible.
  3. Mark everything as internal. Even the main method of your application. Every single method that could be used, will be used.
  4. Test your public API the same way you would for interfaces. Integration tests and so on. Note that your API will be used in unpredictable ways.
  5. Maximize convention over configuration. This is required. Even if your API is a single method you will still need to support this. Just makes your life easier.
  6. Sign, and strong name your assemblies, this is good practice.
  7. Resolve as many FxCop and StyleCop errors as possible.
  8. Check your API is compatible with the Naming Guidelines of your platform.
  9. Provide as many examples as you can, and remember that most of the usage of your API will be Ctrl+C and Ctrl+V from these examples.
  10. Try to provide documentation. Check that you do not have GhostDoc-style auto-generated documentation. Everybody hates this.
  11. Include information on how to find you.
  12. Do not bother with obfuscation. This will help you and your users.

ADDED

  1. API should have as less dependencies as you can. For example, dependecies on the IoC containers should be prohibited. If your code uses it internally. Just ilmerge them into your assemblies.
Mike Chaliy
Thanks it looks cool answer, could you give me a little simple example of code.
Braveyard
+1 Good advice, clearly packaged.
Fredrik Mörk
Emm, example of what code? You can find many examples on open source sites as codeproject.com, codeplex.com, code.google.com, sourceforge.com . I think this is the best way to learn things.
Mike Chaliy
It *is* clearly packaged, now that a couple of us have done major edits on the post.
Robert Harvey
@Robert: sometimes it would be nice with a "shared reputation" function. Even if it's a manual one, that the original author can spread the gained rep among the editors or something.
Fredrik Mörk
yeh, english is not my native.... thanks for your corrections.
Mike Chaliy
+1  A: 

One way to do it is to create a DLL for your main functionality that others will use and an EXE that calls the methods in the DLL. If you want your application to support plug-ins, have a look at the System.AddIn namespace.

Mark Cidade
Nice link. I've been looking around for some article about System.Addin ;)
Jarek