In today’s topic we will discuss API and some related terms. This will help you evaluate a new software for your department and have some meaningful conversation with your IT folks. Target audience: general IT enthusiasts, power users, department heads and decision makers.
In simple term – API is a way to exchange information or data between two software at the code level. We often ask this question to a vendor while evaluating a new software if the software has any (public) API? This helps us to know, if we would like to create an in-house solution in the future based on the data saved in the vendor’s software (database), will it allow us to do so? This could be an important factor in making our decision to acquire a new software. For instance, a common discussion among many Tessitura folks is – is it possible to integrate Mindbody – software used by our In Studio department, with Tessitura – our core business application, so that we can compare and analyze customer data between them? Does Mindbody has sufficient APIs to do so?
Why a software vendor creates a set of APIs when they can simply give their customers direct access to their (vendor) database? Primarily for two reasons: 1. Security – if they give their customers direct access to their database, customer developers may have access to all kinds of data and can create a mess. 2. To make their customers’ life easy – a database can be very complex to an external developer if they were not involved into the original development process. APIs make thing simpler in this case – an external developer can easily extract/update information using APIs to create their custom solutions without getting involved into all the complexities of a vendor database setup and design.
To draw an analogy, suppose we have a visitor at Ballet. Now if we keep the front door wide open and let the visitor get in without talking to the reception first, two things can happen. Firstly it can cause a security problem and secondly the visitor may not know which floor to go to and who to talk to, to get their information. In this case our reception is playing the role of an API where NBoC is the software, WCC (Walter Carson Centre) is the database and the information the visitor needs is data. In ideal case, the visitor should first talk to the reception, introduce themselves, let the reception know where they are coming from, their purpose of visit and who they would like to talk to so the reception can direct them to the right resources. A software API method plays a similar role. When calling an API (or web service method) to read or update data from a database, we have to follow certain protocol – pass our machine address, user name, password and our intention like what we would like to do into the database. If we don’t follow this procedure, it may deny our access. Once this initial handshake is done, API will return what we are asking for which can be simply the first name and last name of a person or any other information that we have requested from the database. It makes a developer life simpler to read or update data from a database without creating any security issues.
In our case, a common API usage example would be Tessitura API. Our Ballet website is created based on this API. Though we have direct access to our Tessitura database, when we pull data, for example – FSC seating information to display on our website, we don’t directly access our database. We call Tessitura APIs to extract those information from our database and display on our website. We also have used this API to create our custom ADS call center solution – NBELS, and some other in-house solutions. On the other hand Tessitura Network may have another set of APIs for their internal developers to create different kinds of Tessitura software like TN Mobile Plus, TNEW, Tessitura Client etc.
Public vs Private APIs
API could be private or public. Private APIs are usually created for a vendor’s internal developers. Public APIs are usually created for customers or external developers. Generally, public APIs are more restricted than private APIs considering security and level of access. Most of the time public APIs can only read data. In case where they can insert or update data, that are also limited to only certain set of data. Some public API examples are Google API, Twitter API, Facebook API, etc. Developers can register with these companies’ developer program and take advantage of using their APIs to create new desktop or mobile apps.
Other Related Terms
You will also commonly hear us using the terms SOAP and REST while we are discussing APIs. These are just different ways of extracting and updating information from a database using APIs. REST is the latest technology and in our case, we are moving from SOAP to REST following Tessitura Network. Other two terms you will hear from us are XML and JSON. These are just different ways of presenting information by an API. In this case JSON is more recent and also easy to read by a software. Tessitura REST APIs can read and return data in both forms. In our case we like JSON since it’s easy to read and create a custom solution based on this. As an end user, you shouldn’t care whether we are using SOAP or REST, or XML or JSON. Whatever app we create based on this will look and function exactly the same as per as you are concerned. This is more of a concern for a developer!
Hope now you have a fair understanding of what an API is and its purpose. Please, note that despite all the goodies APIs can offer, a software has API doesn’t mean we can create any solution based on it. It depends on what level of access or what sort of things that particular set of API is offering.