Companies such as Google, Facebook, Twitter, SalesForce, Netflix have exposed technological solutions to public. Central part of this success is API. Significant amount of traffic comes through API’s. Today API’s are a mainstream and is a business transformation strategy in most organizations.
Let us take a step back and see how it evolved. Application Programming Interfaces (API) are not new in the technology world. Traditionally we had been doing SOA using ASP.Net Web Services with .Net 1.1 and graduated to WCF with .Net Framework 2.0 onwards, middleware technologies like BizTalk to connect to Line-Of-Business applications and commercial ESB’s. Following the tenets of SOA and exposing business layer as services led to application architectures decoupled. Presentation layer can be changed with changing frontend technologies and user experience without having to re-develop the business layer. Layered architectures and API’s exposed through services protected the investment. API’s were also an extension of the product and this provisioned for other applications to interact with it. Service API’s can be consumed with many clients of different technologies. Challenge was solved through making those services interoperable.
Technologies like WCF mostly relied on Xml data contracts and SOAP protocols for interoperability. This addressed the issue in enterprise world. Meanwhile, in the consumer world, with the mobility disruption, applications powered by backend services demanded to consume those services in an efficient way. Xml and SOAP protocols are not an efficient way of communication. SOAP protocol is built on top of HTTP and adds a lot of redundancy. Most of the mobile applications may not need all of the SOAP features. Xml is not an efficient form of data representation especially for a mobile clients with limited connectivity, bandwidth and processing power. Elsewhere in the world, while technologists arguing on SOAP v/s REST and Xml v/s JSON. REST and JSON seemed to be a perfect fit for consumer oriented API’s. Compared to Xml, JSON is efficient and interoperable way to represent data. REST removes the overhead of communication and simplifies by representing the asset in the form of Http Verbs (Get, PUT, POST, DELETE and others).
I would not get into REST v/s SOAP debate. One size may not fit all. Each one was designed to solve specific problems. On a broad classification, API’s can be classified as RPC API and Resource based API. RPC API allows clients to consume data and invoke remote procedural calls on server. For eg: Get Customer Detail, Send Notification, Process Data. Whereas, Resource based API is geared towards consuming and manipulating resources. Eg: Add Customer, Get Orders, Update Inventory.
REST is extremely pleasing. Developing RESTstyle services following all the constraints in the real world pushes limits. Clients that consume REST services may become chatty. A single screen display may require calls to several services. There are ways to solve this by supporting MIME requests and wrapping up several calls into one request and API styles. Sometimes you may need to design services as pragmatic REST. However, for public API’s REST or HTTP (pragmatic REST) services makes more sense.
Today within a Microsoft technology stack, there are two choices, WCF and ASP.Net Web API frameworks for developers to develop RESTstyle services. WCF was originally created for RPC style SOAP based calls and later extensions were added to framework to support REST. REST does not have a first class support in WCF in terms of programming model and hosting capabilities. ASP.Net WEB API address these concerns and take the platform to next level.
ASP.Net Web API is an application framework for developing HTTP services. Remember, ASP.Net Web API is not REST. REST is an architecture style with a set of constraints. ASP.Net Web API lets you develop RESTstyle services. Here you can find more information on ASP.Net Web API to get you started.
Conclusion
The post was to brief on API evolution, need for efficient API technologies and to choose between WCF and ASP.Net Web API Frameworks. And, start a blog series to showcase some of the ASP.Net Web API features and solution to common problems for API design.
Preps Blog 