API is an acronym for Application Programming Interface.
In software application (app) development, API is the middle layer between the front end (commonly referred as UI or User Interface) and the database layer. APIs enable communication and data exchange from one software system to another. Before we delve deep into the API let’s first understand why do we need API.
Requirement of API
Let’s take an example of an airline booking system. Let us imagine that you’re booking a flight on an airline website (Let’s say Emirates.com). You choose a departure city and date, a return city and date and check for availability of tickets. In order to check for the availability, the Emirates.com which is the front end will access the backend to check for the availability of tickets and any seats being available on those dates and what the costs might be.
However, there are other online travel services such as Kayak or Expedia which aggregate information from a number of airline databases. In such cases a user enters the details on the front end which is Expedia.com. Here the user details entered in the Expedia website need to reach Emirates Application to check for the availability. However, since Expedia is a third-party Emirates cannot expose its code or the business logic owing to security issues. Then how does the transaction take place?
Scenario 2: Design Problems
Let’s say the airline website (Emirates.com) has the front end developed in Java, html, CSS. And the backend is developed in Java. All the UI or front end is called Client and all the computing methods, storing information which happens in the backend is called server. And after some years due to more popular and user-friendly frontend frameworks being available Emirates decides to upgrade its UI to angular which uses TypeScript. But since the backend which has all the code is developed in Java it would be difficult to have back and forth communication between front end and backend designed in two different technologies. Such issues are called Design issues.
How API solves the problem?
So in the above two scenarios we address the communication issues by introducing a middle layer between the client and the server. API as the name suggests behaves as an interface between client and server. Emirates creates an API, then this API calls the method in the application whenever it gets hit by a request. This API gets hosted in the same server of Emirates.com.
Here when the user enters the details in the UI , the front end captures all the information in a HTTP request and sends it over HTTP protocol to the API. The HTTP request can be a JSON or an XML. The API then calls the relevant method in the application, let’s say here checkAvailibility. The application or the back end which is developed in JAVA would have libraries which can parse the XML/JSON to query the data from the database and sends back the information to the API. The API then sends back the information to the client over an HTTP response. And this response is interpreted by the UI and presented to the user in a readable format.
In the entire communication process, API is independent of language. HTTP protocol is also independent of language. This solves the problem when design issues arise owing to different language used in developing the client and the server. Also, when third-party travel services like Expedia wants to query the Emirates application. Emirates can only expose its API to the Expedia.com which can communicate to its client via the API.
Types of API
Most commonly and widely used APIs are of two types: Rest API and SOAP API or SOAP WebServices. There’s a slight difference between WebService and API , though they are interchangeably used in current IT world.
SOAP API /SOAP webservice:
They have been in existence quite long
Generally used by legacy applications
They have more authentication and conditions.
They use different format
SOAP uses XML for all messages.
It’s a lightweight protocol
It has flexible ways of coding
Easy to build and maintain
More recent in nature, used by Google, Facebook
REST mostly uses smaller message formats like JSON.
A popular analogy could be SOAP is like an envelope while REST is just a postcard.
Testing of API
There are set of standards that need to be followed for creating an API. From QA perspective there would be testing for the Emirates application, similarly there would be testing done for the UI too. But if ample testing is not done in the integration layer i.e. the API then the desired result couldn’t be achieved. So, it becomes imperative that proper API testing is done to ensure the desired output.
End point: Address where API is hosted on the Server or the Base URL hit from API testing tool.
Since the request is sent over HTTP protocol, HTTP exposes different methods when we communicate with API from the client. HTTP methods commonly used to communicate with the API:
GET- The GET method is used to extract information from the given server using a given URI. While using GET request, it should only extract data and should have no other effect on the data.(RETRIEVE)
POST- A POST request is used to send data to the server, for example, customer information, file upload, etc. using HTML forms.(CREATE)
PUT- Replaces all current representations of the target resource with the uploaded content. (UPDATE)
DELETE- Removes all current representations of the target resource given by a URI.
The above methods are commonly referred as CRUD operations. The API must have each these methods exposed. Let’s say in our previous example a user wants to retrieve a previous booking details by entering the BookingID. This booking ID is sent over a HTTP Get method. The API must be developed in a way that it accepts only get HTTP method. And as a tester we must check the API is built accordingly. The API forwards it to the application which queries the data from the database and gets the desired output from the application and sends it back as HTTP response.
Resources: Resources represent API/Collection which can be accessed from the Server.
Here Google.com is the base URI and Images is the resource or the API
Path Parameters: Path parameters are variable parts of a URL path. They are typically used to point to a specific resource within a collection, such as a user identified by ID
Query Parameters: Query Parameter is used to sort/filter the resources.Query Parameters are identified with’?’.
Multiple queries are joined by ‘&’
Headers/Cookies: Headers represent the meta-data or the additional details associated with the API request and response. They denote the type of message sent i.e. either XML or JSON
Example : Authorization details
End Point Request URL can be constructed as below