If you are in the coding world, it’s likely that you are already familiar with the term API (application programming interface). If you are familiar with APIs, one of the first things that you might do when a customer asks you to build something that can talk to x, y, or z application is to start looking for ways to code an API that can handle those interactions.

If you are just starting to learn how to build APIs like me, below is some baseline info to help make the experience a lot easier. 


Before you begin coding all of the application in the same project, you might want to start by thinking about how you’re going to structure your project. As your application grows, the code will become harder and harder to maintain.  To make things more manageable, we can divide the project into different class libraries. Doing so will make our project more readable for other developers that may work on the app in the future.

In the example above, I have referred to the API as ‘ApiName.’ Of course, in a real project, the API should have a name that appropriately describes it. Also, to maintain consistency and ascribe ownership, I like to add first the name of the customer’s company, store, or organization. In this case, ‘NativoPlusStudio.’

Here are the elements to take note of:

ApiName – The startup project and where the actual Api logic will be written.

ConfigurationModel  – Contains all the configuration properties, like: BaseAddress, ApiKey, UserAgent, Part, MaxResults. These properties are generally static/infrequently modified.

Contracts – Contains all of the interfaces from the project.

Request – Contains the request model for the API.

Responses – Contains the response models of the API.

Services – Where the logic to configure the API is written. Also contains the HttpClient logic and mapping.

Test – Handles all Unit Test logic.


Now that you know this information, you should be able to apply these concepts to your current skillsets and hopefully, this will help you in the future.