Design API – In Good way

Hello all, so its been more then 6 month since I have worked with .Net technology as my current company builds mobile and desktop application on .Net Platform only.

Here in this company, we are following 3-tier architecture, Data Layer, Presentation Layer, Business Layer. But the issue is that we provide solution for all major relational database available like MySQL, MSSQL, Oracle or SQLLite etc.

Because of that our Data Layer becomes very hard to maintain as we have to support multiple databases(We are not using 3rd party provider to keep application lean).

So when new project was assigned to me, I started working on creating new APIs which would provide us a very simple and elegant way of accessing data. And let me tell you it’s very difficult task to create something like that as it would require very detailed domain knowledge.

So in this blog, I will share my experience and points to keep in mind when you are creating and new API(You can use this point in any language, it’s not restricted to .Net platform only).

Keep in mind the following points when you start designing APIs

• Follow Microsoft naming convention
• Use Clear & Understandable naming for Class/Method/Function
• Use Consistent Naming Convention so that it will be easily adopted by other developers
• Use Interfaces (Always)
• Use Stored Procedure
• Follow Design Pattern

Follow Microsoft naming convention

Its very basic point but often overlooked. Follow the naming convention set by your framwork/language(.Net in my case, hence Microsoft Naming Convention)

Use Clear & Understandable naming

Try to think what you objective is for creating APIs, and use suitable for that APIs Module(Package) name and other elements like Class/Method/Function.
In start you may be tempted to use any random word and get to the coding, but believe me it will come hunting you down.

This also makes it very easy for other developers to accept/use your APIs.

Use Consistent Naming Convention

This is related to point one itself, but keep this also mind when developing/designing API.
Follow whatever guidelines have been set by your company or some senior developer, this make it very easy to be accepted and used in old/existing project.
You can consult you manager/Team leader for this if you want to change some convention.

Use Interfaces (Always)

Always! Yes I mean it always. Use Interfaces in almost all cases so that it will be easier to extend you APIs.
This is how , I exposed simple APIs(Not sure about elegant) to API consumer. By Passing different implementation for each databases, I can access the data without breaking the API. Which made it very easy to even extend it.

Use Stored Procedure

If you database supports it, and you have some complex logic, try to implement it in Store Procedure rather then on your code, so that it will be easier to update the logic and minimize the read/write latency to database.

In My case, most of our application was used by client for whom requirement was changing very frequently(Business Logic). And as .Net is compiled language, we have to frequently take the downtime to make even small changes, hence we opted for this stored procedure solution. So that we do not have to redeploy our application for small bussiness logic changes.

This also reduced our client visit as some of the client project were internal and was not accessible from outside of their network.

Follow Design Pattern

Use design pattern when you are comfortable with it otherwise don’t use it just to make everyone happy around you. If you have some problem which can be solved by some design pattern that you can implement and will have its benefit in longer time, then only use it otherwise Don’t.

Solve your problem by using design pattern, Do not look into list of design pattern and see where it will fit. I hope you get this point.

I will keep adding point to this post as I get more time and clarity or will create Part 2 of this blog post itself.

Thanks for reading…