Here at Focused Labs, a leading software development firm, we pride ourselves on consistently building great software while working alongside our customers. By working together, we help you develop better applications and transform the role of technology in your company.
One aspect of software development where we excel at Focused Labs is application programming interface (API) development.
API development is a subset of application development where the dev team focuses on implementing standard protocols for inter-program communication to provide an API. It usually includes implementing legacy APIs using SOAP and RPC or newer protocols, including REST and GraphGL. API development can also be used to transition legacy APIs to more modern types. Once the APIs are in place, teams will use API integration to connect applications through those APIs and APIs that already exist.
Understanding the Different Types of APIs
APIs have existed since the early days of computing when developers needed to have one program pull information from another. Those early solutions used multiple techniques to establish connections and syntaxes to send requests and data. Over time, the industry developed standards for the communication part packet syntax.
Today, most companies use one of the four dominant APIs presented below. Two of them are legacy but still have benefits that keep them relevant, and two are modern and growing in popularity.
Once a type of API is chosen, web services are usually used to connect cloud applications, web applications, or mobile applications to one another.
SOAP (Simple Object Access Protocol)
SOAP is a legacy messaging protocol developed by Microsoft and proposed as a standard in 1999, created as a way for applications to use Hypertext Transfer Protocol (HTTP) (and older protocols like SMTP and TCP) for communication between applications and the Extensible Markup Language (XML) for a message format. It is still in use today because of its simplicity, adherence to well-documented standards, and strong security. The downside is that SOAP uses more bandwidth and memory because XML is verbose, and each side of the connection uses memory to store the state of the transaction until it is done. It is also less flexible from a programming standpoint than more modern API architectures.
A typical use case would be to exchange data between a new e-commerce site and a legacy customer relationship management (CRM) system where you want to record online sales in the CRM. SOAP is a secure and well-defined approach for this because the size of each packet and the number of packets won’t overwhelm the protocol.
RPC (Remote Procedure Call)
The legacy API, RPC, allows one program to run a procedure in another program. The requesting system is the client, and the system running the request is the server. RPCs predate SOAP. The concept was formalized in 1981 and grew in popularity through the next two decades until new standards were developed that required less low-level programming to be implemented.
In an RPC implementation, the client routine builds an API request containing the procedure call and parameters and sends it across a network to an API endpoint on the server. After authentication, the server reads the request, confirms with the client, and makes the requested procedure call. Once the procedure runs, it returns the requested information to the client. The client acknowledges receipt, then ingests the response, and exits.
One of the more common examples of RPC is connecting a modern accounting program to a legacy inventory management tool to update the inventory on hand. Developers would use the legacy system API documentation to create routines that support asking for and receiving inventory information whenever needed.
RPCs are still used because they work for legacy systems or because an application needs the lower-level simplicity, efficiency, and flexibility that RPC APIs enable. The downside is that there are no standards, and every implementation of an RPC API can be unique. You will find RPC APIs in legacy programs, engineering and manufacturing applications, and situations requiring efficient execution and data transfer. Many operating system-level APIs use RPC and high-volume financial transactions where every millisecond counts use RPC.
REST (REpresentational State Transfer)
REST is a modern, standardized web-based API used to connect database applications through the internet. It is the most widely used web-based API. REST stands for REpresentational State Transfer, and strictly speaking, it is an API architecture and not a protocol. It was defined in 2000, and a web service or web API is considered a RESTful API or a REST API if it conforms to the six guiding principles behind REST:
- Uniform interface: A consistent and uniform interface for interactions between clients and servers.
- Client-server: The user interface concern (client) is separate from the data concern (server), letting each side independently evolve.
- Stateless: Each request from client to server must be self-contained.
- Cacheable: The server labels responses that can be reused, so the client doesn’t have to make more requests.
- Layered system: Each component only interacts with the components above and below.
- Code on demand (optional): Servers can return scripts or outlets which can be run by the client.
REST requests usually consist of one of four methods for interacting with data in a remote database:
- GET to ask for data
- PUT to send data
- POST to create a new entry
- DELETE to remove an entry
REST APIs use HTTP for their communication but support multiple standards for packaging the data, with JSON being the most popular. Connections and methods are sent via URLs with arguments, with each URL identifying a specific API endpoint for different types of requests or different sets of data.
REST is most commonly used to connect two or more SaaS applications in the cloud or a web or mobile application to a backend. A common example is processing a payroll run on your HR, accounting, and bank systems. Once payroll is calculated on the HR system, you can initiate a microservice that initiates requests to sync data across the systems.
REST has become so popular because its architecture allows for greater flexibility. Developers can program their APIs using the most common programming languages, usually Python or JavaScript. It also delivers multiple options for connecting. It provides greater scalability because REST is more efficient with data transfer than SOAP, and greater security because it adheres to more industry standards than RPC. Its growing popularity is also driven by its statelessness.
GraphQL
GraphQL is a query language combined with a server-side runtime. It was created by Facebook in 2012, and soon after, they released the specification to the public and made a NodeJS implementation open source.
The query language is how the client specifies data requests, and the runtime and schema exist on the server side. To use GraphQL, the client application forms a request and sends it to a single URL. The runtime receives and executes the request. It then returns data with the same structure as the request. In most cases, JSON is used.
The four fundamental components of a GraphQL API are:
- Schema: A type system that defines the API on the server. It includes what data is available, the structure of the data, arguments, query and mutation types, and scaler types.
- Queries: A set of instructions sent to the server requesting data.
- Mutations: A set of instructions sent to the server that create, update, or delete data.
- Subscriptions: A set of instructions that tell the server to send the client a certain set of data if any of the fields in the subscription change.
This newer API method is growing in popularity because of the flexibility it offers in building queries, its greater efficiency when compared to other approaches, and its ability to fetch data in real-time. In addition, it provides a single endpoint for interacting with the server and allows developers to create single queries that return data from different sources.
API Platforms
API Platforms are related technology that can assist in API development, API documentation, API integration, and API management. They help your team design, test, document, and deploy your APIs. Some are API gateways for common cloud providers like Microsoft Azure and AWS. Others, like Postman and Swagger, provide design, documentation, and other tools. There are also API integration platforms that add workflow automation support, pre-built connectors for public APIs, and low-code/no-code options for people with less developer experience.
Considerations Before Transitioning From Legacy APIs to Modern APIs
There are many reasons to move from older APIs to more modern methodologies and also some challenges to take into consideration. Before you get started, you should make sure you understand the reasons to transition and also have a good grasp of what challenges you might face. Here are some of the most common justifications and difficulties we see when helping our customers with transitions:
Reasons to Transition
Scalability: Modern APIs like REST and GraphQL offer better scalability for growing applications.
Performance: Since GraphQL allows you to construct more efficient queries, you have to make fewer API calls.
Flexibility: Both REST and GraphQL provide greater flexibility in how you connect, the format of your data, and the services you use to connect APIs.
Interoperability: The older APIs were designed when cloud-native applications were immature or the microservices had become popular. If you are connecting many digital assets, modern client-server architecture can be beneficial.
Challenges and Situations to Consider
Security: Always monitor security and assess how tight your security needs to be. You may be keeping a legacy SOAP API around to address security vulnerabilities that no longer exist. Understand your current and long-term needs and make sure they are addressed before undertaking a migration.
Cost: Updating an API takes time and money. Take a realistic look at the cost vs. the benefits of implementing the transition. Don’t forget to include the cost of future maintenance and adding functionality with increased efficiency and sometimes new revenue streams.
Continuity and Legacy Integration: Making the move from a legacy API to a new one can take some time, and work might be disrupted. Conduct your API testing in an environment called a sandbox before replacing the older APIs to avoid this issue.
Focused Labs API Development Process
At Focused Labs, we use industry-standard software development practices and methodologies to create outstanding software applications, including custom API development and legacy API transition. What sets us apart, besides our outstanding team, is our development philosophy.
Discovery and Planning
We meet with the customer and work to understand client needs, business processes, end-user expectations, and what the existing digital systems and APIs are. Once specifications are documented, we then identify the best API type for the project and plan out the effort.
Design and Prototyping
Our team uses their experience, input from stakeholders, and the specifications from discovery to design the APIs with scalability and long-term needs in mind. We then prototype those designs, exercise them, and gather feedback that we use to iterate on the design until we meet the effort’s goals.
Implementation
Once the design is finalized, it's time to develop robust APIs. We utilize modern frameworks and tools to ensure an efficient and robust implementation.
Testing and Quality Assurance
The APIs are then rigorously tested to meet the functional requirements, compatibility expectations, and performance goals. We employ continuous integration and proven deployment practices to maintain high quality throughout the testing and validation process.
Deployment and Maintenance
We then deploy the tested APIs with processes designed to make transitions smooth and minimize or eliminate disruptions to user and business activities. Once in the field, we provide ongoing maintenance and support to adapt to evolving business needs.
Case Studies and Success Stories
The best way to get a feel for API development is to review some case studies of projects we have completed for customers:
- Aperture Health needed to work smarter and transform its software development team to move toward agile methodology. They chose an API development project to create a primary source verification (PSV) API enabling clients to verify the credentials of medical professionals. The final product turned a three-day manual process into a four-hour one. We then went on to develop invoicing and billing API clients.
- When BTR Energy needed to find a way to onboard clients for their EV charging solution faster, they turned to Focused Labs to build a standardized REST API. Not only did this help BTR Energy quickly add three customers, but it also helped them raise more venture funding. The tool included a user-friendly front-end dashboard to view everything along with the API.
- Hertz wanted to improve their digital transformation and open up new revenue streams. One project was building a backend API and then doing the API integration with a partner to improve last mile package deliveries. The solution helped Hertz and their partner increase performance and build a new revenue stream.
Getting Started With Your API Development Project
As you can see, API development can upgrade your existing data transfer between applications or create new and more powerful ways to improve user experience and get the right data to the right place at the right time. If you’re ready to get started on an API development project, the best place to start is to document which apps you need to connect, what data you need to move around, and who your stakeholders are.
Once you have that information in place, build your team to design, test, and deploy your APIs. A great way to get a head start on that process is to partner with Focused Labs to not just create the solution, but to put a culture in place to keep adding to and improving those APIs yourself. Reach out, let's build something together.
