Application Programming Interface
(API)
As described in the Service Oriented Architecture section of this website, components are built in a way that each service, or component, can standalone, but can also be connected to other services or components in an integrated fashion. Using the Lego block analogy again, the API represents the connectivity components of each Lego Block. In Lego block terminology, each block has "studs" and "tubes" all with precise standardized measurements for universal connectivity. In case you are interested it is 4.8 mm for the diameter of each stud in the large Lego blocks.
Characteristics of a Good API
The development of a good Business Application should be made up of many components. The connectivity of these components (i.e.The API) should possess the characteristics as described below:
Simplicity
The overall business problem being solved by an Enterprise Application is complex. With good design, however each component can, and should be designed for simplicity. Good API's offer simplicity, and it takes a good bit of effort to preserve that simplicity. There is both the Art and the Science involved in writing good API's and good components. Developers' often have a tendency to try and solve multiple problems within one component. This adds complexity and increases the chance that component will have to change over time. An elegantly designed component performs only one function and an elegantly designed API only has one interface to that component.
Abstraction
Abstraction means your API provides for an overall solution to a problem, but the details of how it performs the function is hidden from the users of the API. This adds value to the user as they do not need to know all the inner workings behind your API or the component that it is connected to. They need to know what input it needs and what output they can expect from it.
Discoverable
Developers will immediately start developing something from scratch unless it is easy for them to discover a component that they can use. With simplicity and abstraction in place once they discover the API and the component they will want to use it. Many attempts have been made to force developers to re-use components, but if the API's are hard to find or hard to use the developer will not use them. An essential part of any development environment is an effective Library of re-usable services.
Vendor Agnostic
The last thing you want in an Application interface is to depend on a particular Vendor Product or Vendor announcement of the day. The last thing a software vendor wants is for you to understand this! You are connecting two computer systems, or components thereof, so there is no need for additional software between the two systems. If you add the third party complexity you also create an interface that will become obsolete as the Vendor moves on to new releases of the interface software. Here are two examples of how you would remove any dependency on third party software for your interface.
1. You are receiving input from one process and you are adding additional value and then passing that process on to a subsequent process. (eg. A supply chain application). The ideal interface occurs when you align the data from the output of one process so that it is exactly what is expected as input to the receiving process. This interface should last as long as the business connections between those two processes remains the same. You eliminate the need to do software upgrades just for technologies sake. The world of Electronic Data Interchange has been using this technique for decades and will continue for decades to come. There are trillions of successful API's being executed in business every day.
2. You require information from a separate process (could be from an internal process or a process from an external system or an external Company. You formulate the API as a "request for information" and you provide all the necessary data so the receiving process can understand the question. The receiving process will look up the answer from within its own system. The requesting process does not know, or care, how the receiving process looked up the answer. The two systems are completely independent from the technologies that each one uses on their own.
as an example... In the world of shared Automated Banking machines, a cardholder from one Bank uses an ATM from a different Bank. The Bank that controls the ATM will create three API's to send to the Bank that holds the cardholder's account. The first API asks if the Pin number entered was correct. (encrypted and secured of course) The second API asks if the cardholder has enough money to cover the requested withdrawal amount. The third is an API instruction to say the transaction has been completed. Neither Banking system knows anything about the technology of the other system. They do not store any information about each other. They just know the question and answer as dictated by the API's.
1. You are receiving input from one process and you are adding additional value and then passing that process on to a subsequent process. (eg. A supply chain application). The ideal interface occurs when you align the data from the output of one process so that it is exactly what is expected as input to the receiving process. This interface should last as long as the business connections between those two processes remains the same. You eliminate the need to do software upgrades just for technologies sake. The world of Electronic Data Interchange has been using this technique for decades and will continue for decades to come. There are trillions of successful API's being executed in business every day.
2. You require information from a separate process (could be from an internal process or a process from an external system or an external Company. You formulate the API as a "request for information" and you provide all the necessary data so the receiving process can understand the question. The receiving process will look up the answer from within its own system. The requesting process does not know, or care, how the receiving process looked up the answer. The two systems are completely independent from the technologies that each one uses on their own.
as an example... In the world of shared Automated Banking machines, a cardholder from one Bank uses an ATM from a different Bank. The Bank that controls the ATM will create three API's to send to the Bank that holds the cardholder's account. The first API asks if the Pin number entered was correct. (encrypted and secured of course) The second API asks if the cardholder has enough money to cover the requested withdrawal amount. The third is an API instruction to say the transaction has been completed. Neither Banking system knows anything about the technology of the other system. They do not store any information about each other. They just know the question and answer as dictated by the API's.