The ASP.NET Web API framework was introduced recently into ASP.NET. I touched on it some previously at an overview level, but would like to dig in a little more at this time to show the power of having a true Web API in your product.
Overview
From a high level, leveraging the Web API framework in ASP.NET allows you to easily build HTTP based services geared at reaching browsers, desktop or mobile clients. By creating a responsive layer of RESTful APIs for a product, the platform immediately becomes a much more adaptable and scalable solution. The simple act of ensuring all 'real' application logic is handled behind a RESTful API call, an inherent separation of interests is manifested, which enables a more loosely couple application at every layer.
ASP.NET Web API Infrastructure
At its base, the ASP.NET Web API mechanism is a simple adaptation of an HTTP service. Web API can be used along with WCF, but realistically, they are two means to create virtually the same thing. The main aspect of a Web API layer is the ability to create an API project within a given solution that allows user stories to be executed via RESTful calls to the services. Microsoft has a great tutorial for creating a simple Web API project as an introduction to the platform. For those familiar with MVC, this exercise should be very straightforward and easily worked through. In fact, as you work through this, it will probably become clear that there is very little difference here than a standard MVC application. The main difference is that Web API uses the HTTP method, not the URI path, to select the action. But, you can also use MVC-style routing in Web API if that is more your style.
Dynamism
Leveraging an API infrastructure as a service layer for you web application gives you the ability to manifest any client on any platform without recreating application intelligence. Some of the main features of Web API allow for the creation of a dynamic service layer that can interact with multiple versions of the same platform, 3rd party vendors, customer integrations and most importantly, your own application. A strong API will have an entry point to accommodate the same list of user stories that the main presentation layer in your application presents to a user. The API layer should handle modeling, security, extensibility and scalability. This allows for the consistent use of application logic and business rules across multiple consuming platforms. API/SDK layers should be manifested by version, with all historic versions co-existing. A single set of business logic and data access logic should persist across versions of API. This allows forward movement without backward degradation. By adhering to the rule of the eternal public interface, this is an achievable goal.
The 'Real' API
While the main focus of this post is the ASP.NET Web API offering, I would like to make a point regarding what an API should be in my opinion. An API should be a complete manifestation of every user story that exists in your application. The API should be a service layer that is not the data access layer, nor is it the main business logic layer. It is the manifestation of User Stories. This type of layer has been called the User Story Layer and the services contained within have been called Complex Services. This is a logical regrouping, or coupling of specific business logic tasks to create a user story. A user story should be completely executed within its single methodological representation, including input validation, security and access validation, activity logging and return values. All manifested user story methods should assume no knowledge of requirements, modalities, system or data flow from any client executing the method. Data access and business logic should never be directly exposed to an end user, third party or otherwise. Data access and business logic should be separated from each other as well as from the API/SDK/USL. This enables the ability to quickly couple existing sets of logic into a new user story without having to accommodate situational elements inside the business logic layer. For more information on building a strong SOA, see some of my previous posts here. For a theoretical discussion of the purpose behind SOA, check this post. A framework that has been built with this decoupled approach of singularly responsible object residing behind globally accessible services will much more easily allow for productivity items such as Continual Integration, Continual Deployment, and fully automated testing.
Your First API Client
The short answer here is that it’s your application. A robust API should first and foremost serve all logic to your own applications. You have to create your API and then consume it. This ensures that all changes made are not only accounted for in the API, but are placed there with intent. You have to eat your own dog food. In a web development and agile deployment environment, the ability to decouple code and responsibility of objects is the best friend you will ever have. Approach your web design with intent and long term vision for things like scalability and performance. Understand that you need to support multiple versions of your service layer and extend your data objects over multiple versions. A properly architected system will ensure you are able to respond to changes in your market and your market requirements much more quickly than would be the case otherwise.
