Integrating APIs - the Types and Processes involved

APIs and API integration has become an increasingly ubiquitous aspect of the digital market and incorporated into more and more products over the past decade. Therefore, it is important to better understand how integrating APIs is an important part of business life. We should consider APIs as a form of business contract that can have a tremendous impact on a business strategy. The importance of APIs and their integration demands a sense of understanding from the start of a project. For this reason, it is important to consider the Project Discovery Phase as well as the type of contract to enter. The most beneficial contract model is the time and material which provides the best control and vision over a software development project. We use API integration for many reasons according to their purpose, such as allowing the backend to communicate with the frontend. There is also the API integration that extends a business or website by offering additional services, such as geo-locating services for finding directions to a business.

During this article, we will discover what is API integration by looking at APIs by Policies and APIs by Uses. Some benefits of API integration will surface as we also look at the different APIs, such as REST APIs and SOAP APIs, and when to use each one. Further to this, we will look at more detailed information on the role of APIs and the actual integration with examples of language.

If you would like advice on your Project Discovery Phase, Go Wombat provides a comprehensive analysis of the scope of a project. Call us for more details.

APIs by Policies

These policies determine who can use and what type of information or function is allowed through the API.

Private APIs

This is for internal company use and aimed at improving functions and communications. We provide these to integrate existing IT systems or applications. The private aspect allows us to control fully the application by us as the developer or the client. For example, when the backend database provides requested information to be placed on a screen. This form of communication is direct and only between the front end and the backend.

Partner APIs

These forms of API are openly promoted but shared with business partners who have signed an agreement with the publisher. The common use case for partner APIs is software integration between two parties. A company that grants partners access to data or capability benefits from extra revenue streams. At the same time, it can monitor how the exposed digital assets are used, ensure whether third-party solutions using their APIs provide a decent user experience, and maintain corporate identity in their apps.

Public APIs

Also known as developer-facing or external**,** these API integrations are available for any third-party developers. A public API program allows for increasing brand awareness and receiving an additional source of income when properly executed.

There are two types of public APIs – open (free of charge) and commercial ones. The Open API Definition suggests that all features of such an API are public and without restrictive terms and conditions. For instance, it's possible to build an application that uses the API without explicit approval from the API supplier or mandatory licensing fees. The definition also states that the API description and any related documentation must be openly available and that the API can be freely used to create and test applications.

Commercial API users pay subscription fees or use APIs on a pay-as-you-go basis. A popular approach among publishers is to offer free trials, so users can evaluate APIs before purchasing subscriptions. Learn more about how businesses benefit from opening their APIs for public use in our detailed article on the API economy.

Go Wombat are highly experienced with API design and integration. Contact us to discuss your project.

APIs by Uses

Database APIs

Database APIs enable communication between an application and a database management system. Backend developers work with databases for many reasons for example, by writing queries to access data or change tables. Some Database APIs, for example, allow users to write unified queries for different databases, either proprietary or open-source.

Operating systems API

As the title suggests, this group of APIs defines how applications use the resources and services of operating systems. Every OS has its set of APIs, for instance, Windows API or Linux API.

Remote APIs

Remote APIs enable standards of interaction for applications running on different machines. In other words, one software product accesses resources located outside the device that requests them, which explains the name. Since two cloud-based or remotely located applications are connected over a communications network, particularly the internet, most remote APIs are written based on web standards. Java Database Connectivity API and Java Remote Method Invocation API are two examples of remote application programming interfaces.

Web APIs

This API class is the most common and often used as part of business processes. Web APIs provide machine-readable data and functionality transfer between web-based systems which represent client-server architecture. These APIs mainly deliver requests from web applications and responses from servers using Hypertext Transfer Protocol (HTTP).

Go Wombat can help your project by assessing your needs and providing a detailed analysis of your project. We can advise on the best route forward using APIs. Contact us today for a chat.

Features of APIs

Specifications

Although there are many forms of API, the two most common APIs are SOAP and REST.

SOAP

Simple Object Access Protocol – is probably the better known of the two models as it is the older. SOAP relies heavily on XML, and together with schemas, defines a ‌strongly typed, and some would say, rigid messaging framework. For example, the XML structure explicitly defines any request and response process. Each input parameter is defined and bound to a type: for example, an integer, a string, or some other complex object.

The following is an example of SOAP code. The message is requesting the price of an item in stock.

The frontend makes a request, through the API to the database, this time, of the price of an item in stock. The backend then returns the price, through the API, of the identified item.

SOAP requires more capacity for its usage. Since SOAP messages contain a lot of information inside them. The amount of data transferred using SOAP is considerably more than other APIs like REST.

As the name states, SOAP is a protocol and was designed with a specification. It includes a Web Service Description Language (WSDL) file that has the required information on what the web service does besides the location of the web service.

All language within a SOAP message is in XML as SOAP can only deal with this language. As a result of this constriction, SOAP is unable to make use of REST functions.

On the other hand, REST is an architectural style and can be adapted to several languages. In this case, REST can make use of SOAP as the underlying protocol, as it is an architectural style API.

REST

Representational State Transfer. It is a software architecture style that relies on a stateless communications protocol, most commonly, HTTP. Although REST structures data in XML, YAML, or any other format that is machine-readable, however, JSON is most widely used.

REST follows the ‘object-oriented' programming paradigm of noun-verb. REST relies very much on data-driven communication, compared to SOAP, which is strongly function-driven. A common referral is RESTful APIs or RESTful web services, which are interchangeable.

We use REST APIs as we believe they provide a greater range and flexibility of programming.

Web APIs that comply with REST architectural constraints are called RESTful APIs. These APIs use HTTP requests (object-oriented) to work with resources: GET, PUT, HEAD, POST, PATCH, CONNECT, TRACE, OPTIONS and DELETE.

The following is an example of using a “GET” request in REST with JSON language.

The example shows how a request for a specific news item would be communicated between the front end of a web page and the back end or database, using an API.

We have an endpoint "example.com/news/". This endpoint allows you to get or view a list of topical news items. When the frontend makes a “GET” request to this endpoint, it returns data in JSON format:

The frontend then arranges this information in the right places. A well-presented list of news from titles is what the customer sees. The endpoint of the detail page is hidden behind the title. When you click on a specific news item, the frontend makes another request and uses the endpoint hidden behind the news title. The backend returns detailed information regarding this news in JSON format too:

Once again, the frontend arranges this information in the right places, as in the previous step according to the design.

As can be seen, the amount of data within a REST with JSON API is considerably less than that of a SOAP message. This simplifies the coding and increases efficiency.

When to use REST? ……. When to use SOAP?

As we have seen, both SOAP and REST are useful in different situations according to their specifications. Here are some of the key indicators that determine when REST and SOAP API technology should be used for web services.

REST

As REST consumes far less bandwidth due to containing less content, REST should be used in instances where network bandwidth is a constraint.

Statelessness

If there is no need to maintain a state of information from one request to another then REST should be used. For example, if there is a need to transfer information through a specific process such as a shopping website, REST is NOT an option. The ‘state' aspect is where there is specific data to be used to inform or influence the following stage. We can take the example of any online shopping site. These sites normally require the user to add items for purchase to a cart. To complete the purchase, these items are then transferred to the payment page. The state, or number, and other specific details, of the items need to be transferred to the payment page to continue processing.

Caching

The idea of caching is to store a large number of requests, and for this, REST is the best solution. Often, a client may request the same data multiple times and potentially increase the traffic to and from the server. By implementing an intermediate cache, the most frequently requested data can be stored and retrieved, eliminating the need to visit the server.

Ease of coding

Coding REST Services is faster than SOAP due to the content, and so, subsequent implementation is far easier than SOAP.

SOAP

The need for systematic or progressive processing and subsequent use of the data requires a level of reliability and security. This calls for the new SOAP standard of SOAP 1.2 which provides a lot of additional features, especially when it comes to security.

If a formal means of communication is required, for example, if both the client and server have an agreement on the exchange format, SOAP 1.2 provides rigid specifications for this type of interaction.

An example is our online shopping site from before. As mentioned, the purchaser selects items before proceeding to the checkout page. We can assume that there is a web service involved that transacts the final payment. This form of systematic progress, or firm agreement, suggests that the service will only accept the cart item name, unit price, and quantity. If this is the case, then it would be better to use the SOAP protocol.

Stateful operations

If an application has a requirement that ‘state' or specific data needs to be maintained from one request to another, then the SOAP 1.2 standard provides the structure to support such requirements. Once again, referring to the previous example of the payment system of the online shopping site.

The Role of APIs

In a continually evolving digital economy, APIs are necessary to enable new services continuously, but the need for digital-first strategies makes APIs more of a priority than before. Every organisation is confronted with the need to make changes fast and adapt to new ways of conducting their business. APIs are relied upon to streamline this process of transformation.

The benefits

An API acts as a gateway for an enterprise's digital assets by allowing the enterprise to quickly build new digital consumer experiences. This can open up new revenue channels and expand existing revenue channels. In addition, it enables the enterprise to cater to future expansions.

All the above benefits depend on how we design and implement our APIs and the rest of the integration use cases.

To discover the benefits of using an experienced software developer, such as Go Wombat, *call us *today.

Integration-first vs. API-first

Nowadays, there are two approaches adopted by enterprises when developing their APIs, either RESTful or other. These approaches can be described as integration-first or API-first.

An integration-first approach can be described as a bottom-up or back-to-front approach where we build the integration logic first on top of backend services. The integrated services (also known as composite services) are then exposed as managed APIs to users.

With an API-first approach, the API is designed and then implemented along with the integration logic.

An integration-first approach

Based on the project requirements, the backend development team develops the integration layer exposing the existing systems.

The backend teams expose the backend services through REST APIs. Then, the frontend team starts connecting their web and mobile applications to these APIs.

The frontend team finds it difficult to implement some features with existing APIs and creates a change request (CR) for the backend team.

The backend team updates the backend to cater to the new capability and improve the API.

This will go for several iterations until the backend and frontend teams agree on the proper API for each functionality.

This approach could adversely affect the project timelines and costs. Communication between the teams may be reduced, and any design flaws are discovered at a later phase of the project.

API First Approach

An API design-first approach is seen as a more collaborative approach, the frontend and backend teams work together to design the APIs.

We achieve a better understanding of the user experience through the involvement of the frontend team. This inclusion provides valuable information for the developer. This also works to improve the general design cycles, as the developer does not need to wait for design phases.

Implementations can take place simultaneously as the frontend teams can use any mock backend for their development work.

Often there can be miscommunications between teams requiring changes in the backend and APIs. However, this process can help eliminate these and reduce delays and going over budget.

Conclusion

During this article, we have delved into integrating an API and looked at some of the aspects surrounding this complex tool. The methods of integration have been covered, as were the various API according to several factors.

We have looked at the key differences between REST and SOAP, as well as the possible applications for each. While APIs can be vastly different in their configuration and operation, their underlying concepts remain the same.

If platforms and advanced gadgets are the building blocks of technological developments, then API integration is the glue that holds them together.

There's currently a booming market for API integrations and API integration tools, and it is safe to assume that we will see a lot more of this type of technological advancement and collaboration to address ever-increasing elaborate demands on businesses.

Go Wombat has over seven years of experience in software development and designing and integrating APIs. To find out how we can help maximise your business, call us today.