Digital transformation is happening everywhere with the involvement of mobile and cloud technologies. Application Programming Interfaces (APIs), once seen as developers’ tools, are now being exposed to the market. However, digital transformation is not an easy task. It involves the ability to bring in multiple technologies to create distinctive and disruptive services to the market. To make this happen, we must be able to retrieve data/information from disparate sources and provide them to multiple consumers in various formats.
While navigating through Digital Transformation, most organizations were not effectively using the best features of Rest API standards, Best Practices, and the flexibilities of it. They ended up with the same issues they had in their old environment and wasted a lot of time and resources to resolve those issues. Many organizations are not following the best practices and key concepts.
Understanding Issues in API Design and Implementation:
A majority of APIs are built with Monolithic Architecture, which has all business functionalities in a single API. This has drawbacks and is pretty high risk; it’s hard to change and maintain, and it takes time to deliver to the market. If any changes to the source and target systems are required, we need to rewrite the entire functionality, as it’s rigid and sticks to serve only one function that cannot be reused. It’s not flexible, reusable, nor scalable, cross-functional, or extensible, and it can’t be used for multiple consumers at the same time. This is why we need to build more APIs to serve multiple consumers to get similar functionality since each source has a different set of input and output parameters. Most of the implementation will be redundant in this case.
APIs serve enterprises by communicating with different systems because it’s hard to troubleshoot when there are connectivity issues, system failures, or unavailability of systems. If any of the systems are altered or retired, we need to rewrite the API and put effort to test the entire functionality again and again, which is time-consuming, costly, and impacts the existing users as well.
Another factor we’ve identified is multiple domains related to functionalities of the organization that have been incorporated within the same API. Another drawback is if any domain-related changes happen, we need to test all other domains to guarantee functionality.
Examples of API Implementation Issues
We’ve seen the below issues with the Coarse-Grained API implementation at one of our customer sites. They built an API that deals with customer-related CRUD operations, tokenization of credit card transactions, and customer loyalty operations dealing with the JSON data format.
After implementing this API, we received the following requirements.
- Another application is looking to perform customer-related operations with XML as a data format.
- Mobile applications and web applications are looking for a different set of request and response fields.
- Some applications need enhanced output fields by communicating dependent services.
- In the future, we need to update the customer-related CRUD operations to Salesforce along with the existing system.
- Other Internal APIs need tokenization functionality in their individual APIs and the same for loyalty points as well.
- In the long-term perspective, they want to change the back-end storage from Oracle to Salesforce for customer and loyalty data.
For all of the above scenarios, we can’t leverage the existing API implementation. Instead, for each situation, we need to build a brand-new API that’s serving similar business functionality.
Examples of API Security Issues
Most implementations were just done for Security Socket Layer (SSL) Offloading and did not apply any other security constraints at the external and internal gateway level. This means that their system is not robust and is susceptible to crashes from external attackers. If proper security constraints were not in place, we may get DoS (Denial-of-Service) Attacks, Anti-farming issues, and the API then becomes unresponsive for users. As access permissions are not defined with user roles, everyone can access all API functions, which causes unnecessary data traffic, makes the API unresponsive with overload, and negatively impacts the business. Since API validation is not in place, we can face issues like code injections, malicious entity declarations, and parser attacks as well.
Examples of Insufficient API Policies
Most of the APIs were not having Authentication, Authorization, threat protection, or Quality of Service-related policies applied to their APIs. If authentication and authorization policies are not defined, intruders can access the API and steal the information. Since there is no control over the number of requests made to the API, the API will be overloaded with calls and API performance will be degraded. In some cases, APIs are unresponsive and “out of memory” issues will occur. Without applied threat protection policies, the API will not be safe from malware, risky file types, or website/malicious network traffic.
Insufficient API Versioning
Most of the Organizations are not maintaining the API versioning. Instead, they are building the API’s on-demand as opposed to leveraging existing APIs that serve the same functionalities. If we don’t have versioning, you will see duplicate and redundant APIs in the system. If any changes need to be applied, we will need to rekey the multiple versions, which is a time-consuming process and requires manual maintenance, which is not a good practice.
Let’s explore a scenario: we built the customer API version 1.0, which is saving customer data to Oracle in the backend. As requested by the customer, we decided to change the backend from Oracle to Salesforce. The customer expects both old and new versions running for some time. If we did not maintain the versioning, we cannot meet the customer’s needs. In the meantime, if any issues happened in Version 1.0 of the API, we don’t have control, nor can we fix the issue immediately.
Inconsistent API Naming Conventions:
We have not seen unique naming conventions for each resource, endpoints, query parameters, URI Parameters, Headers, or body elements in the content. Some of the inconsistent examples are below.
- http://api.example.com/inventory_management/managed_entities/{id}/install_script_location – This example is not readable.
- http://api.example.org/My-Folder/my-doc – This example doesn’t have the same case.
- http://api.example.com/createcustomer – This example forces creation in the resource name.
- http://api.example.com/searchcustomer/ – This example has “/” at the end.
- http://api.example.com/$payment – This example has special characters
- http://api.example.com/:Id/ – This example is not self-explanatory and not readable.
To access XTIVIA’s complete guide to API best practices, you can download the full eBook, “API Standards and Implementation Best Practices,” here. If you have any questions, please engage with us, either through the comment section below or by reaching out to us here.