In a typical enterprise network we’d rarely see everyone using the same applications on exactly the same platform and with a uniform configuration. Instead, we’d expect a range of applications for different things, running on a variety of platforms, and using different data sources. This is one reason why, in my workplace, at least 50% of the applications we develop are used within Web browsers, and most interact with each other using some form of Application Programming Interface (API). This is also why major Web 2.0 services, such as Twitter and FaceBook, publish APIs for developers to integrate features into third-party software.
Strictly speaking, an API is an entry point into an application, platform or service that enables an external entity to use its resources. For example, the Windows API enabled third-party software to use the native services of the Windows NT operating system.
Scaling up this concept, multiple applications can use each others’ APIs to exchange information efficiently without going through another mediating layer, or one service can use another as a data source. This is likely something I’d be doing a lot more of in the near future.
To demonstrate how a very basic API works with Twitter, I created a standard Windows Forms application around the search query example on the Twitter API page. When the button is clicked, the application takes the content of the text box and appends it to the search query URI, with the
GET command in the HTTP header, thereby sending a REST request:
A REST request has two defining features: 1) The command/requests are sent as URIs, 2) It makes use of the
PUT commands within the HTTP header.
Here the Twitter server will extract the ‘
search?q=%40[search term]‘ part of the URI, and perform whatever operation was mapped to that string. It will then return the HTML for the result, and this will be rendered by the local application’s Web Browser element:
An ASP.NET Web API Example
The next example is something I borrowed from a Web API tutorial, to show what happens on the server end when an ASP.NET service responds to a REST request. An MVC Web application roughly works by routing requests to whichever ‘controller’ according to the URI. In this example, the requesting URI takes the form:
The standard ApiController class has a set of empty controller methods for handling whatever valid requests the application might receive.
In the tutorial project, the application has a catalogue of products that can be searched by their IDs. When a user requests an item, the request is routed by the server to the ‘products’ controller, and the ‘Id‘ value is passed to the relevant controller class.
Basically the ‘Id‘ value relates to whatever the user submitted in the Web page form, which is sent as a query value to the server: