API(Application program interface)

API (Application program interface)

An application program interface (API) is a set of routines, protocols, and tools for building software applications. Basically, an API specifies how software components should interact. Additionally, APIs are used when programming graphical user interface (GUI) components. A good API makes it easier to develop a program by providing all the building blocks. A programmer then puts the blocks together.

Difference between API and SDK

While the API is primarily focused on interaction methods for the data and logical layers of an application, the Software Development Kit) SDK will often provide means for varying the user interface as well. The purpose of the API is integration and data exchange while the purpose of the SDK is typically application customization.

APIs provide data that often requires disambiguation and intermediation before it can be exported to another API waiting to receive data. Why? Because the data formats differ, the field names, lengths, types and logical layouts are all different. In addition, the physical file structures and data transport methods may be completely different. How can we “manage” all these differences in Enterprise APIs?

First, we need to recognize that not all APIs are alike in purpose or form. Not only are there varying types of APIs, some are poorly designed and documented while others perform very well and according to their written specifications.

Types of APIs

APIs vary in important ways depending on whether their transport mechanism is based on hypertext, source code or binary functions.

Web Services APIs

Many APIs today are based on typically hypertext resident Web Services standards such as REST, SOAP, XML-RPC, and JSON-RPC.  Web Services APIs are commonly used in web applications and as part of a Service-Oriented Architecture (SOA) approach often preferred by large enterprises.

Simple Object Access Protocol (SOAP) based Web Services are based on a WC3 protocol. WC3 states that “SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment.” It is often associated with Web Services Description Language (WSDL) and UDDI. WSDL is defined as a language based on XML for describing Web services. WSDL lets you know what you should expect the Web Service to do. WSDL is machine readable and human readable as are SOAP and UDDI. The Universal Description, Discovery and Integration (UDDI) specification is a means of providing a directory of available Web Services. I realize that calling REST Web Services a “standard” isn’t accurate.

RESTful Web Services are any of a group of approaches that conform to the principles of Representational State Transfer (REST) architecture. REST principles call for stateless client/server architecture typically based on HTTP.  They conform to the use of Universal Resource Indicators (URIs) and use the CRED methods of PUT, GET, POST and DELETE. Resources are represented and therefore decoupled from their source. Messages are self-descriptive. Stateful interactions are achieved through hyperlinks. Since all interactions with resources are stateless because the requesting message is self-contained. Explicit state transfer is used to achieve stateful interactions. Transfer XML or JSON are used.

Source-Code APIs

Source code APIs offer libraries of objects, classes, etc. Source code APIs are often used in development projects to create a composite application. The calls are made according to the standards of the application environment such as J2EE or .NET.

Legacy APIs

A variety of legacy approaches to application interfaces employ flat files, remote object protocols, operating system interfaces, hardware APIs, communication protocols, message queues and other means. Referring to these as a legacy is not meant to be a pejorative, but rather a way of grouping a variety of long-standing and established, albeit somewhat older protocols together. A good example of a legacy API type would be (COMMON Object Request Broker Architecture) CORBA. CORBA object types can occur in many instances. So while the customer object type does not change, each instance of the customer object type is associated through a token to its data.

To find the smarter way to manage enterprise app integration, you need to look at what the most effective IT organizations do to manage the challenges of API integration complexity, security, scalability, and resource demands.  You also need to look closely within your own project to identify the process gaps. Finding best practice approaches to API security and best practice approaches to API scalability are at the top of many organizations IT priorities. Just as important, however, is the need for business process integration efficiency and a well-architected approach to application integration.

Benefits

Integration with other systems
Let’s face it, most companies today (large or small) are running their business using a variety of software programs. They might use one piece for accounting, another for CRM and yet another for project management. The need to tie these systems together is becoming increasingly important. APIs are a way to do just that throughout your entire organization. The better the API, the more you can integrate the systems and run your business more efficiently.

Take control
Not all user interfaces are the same. The system you own could be very complex and do a lot of things. Maybe you like the software overall but found that your people find performing a few specific tasks difficult and time-consuming.

Entering the time, for example, could have been left as an after-thought as compared to other software capabilities. However, in your company, time entry is critical and employees are finding the screen unusable. Perhaps all the data points you need to capture are there but you just can’t enter them in easily. A well-written API would provide you with the tools to redesign that interface into something that better suits your needs. Just like that, a set of ugly screens turns into something employees will use and appreciate. They can even be branded to your unique company.

Engage your customers and vendors
Perhaps your system runs your entire organization. Often the next logical step is to get customers or vendors interacting with your data to improve efficiencies. In the case of your customers, it would make sense to include them in your process. With a well-written API, you can extend portions of what you do to the web both relatively easily and with confidence it will work the way you need it to.