What is an APIApplication Programmatic Interface An intermediary between two Applications/Systems or Generic Connectivity Interface to an Application. Software applications communicate with one another via APIs. Learn more about APIs and Private Networks More?
An API (Application Programming Interface) is an intermediary between two applications/systems or generic connectivity interface to an application. Modern APIs possess several characteristics that make them a very valuable and useful technology:
- Not just code, but products as well. Their design and documentation are geared towards certain audiences, mainly developers, and follow a product life cycle. The DX (Developer eXperience) products are those designed for the best developer experience. It is easy for developers to adopt and maintain industry standard specifications, documentation, and versioning.
- Security and governance are well-defined, and performance and scale are measured.
- They adhere to standards like REST, Open API, and GRPC, which are developer friendly and broadly accepted.
Developers are able to execute business/technical functions without needing to understand the details because APIs encapsulate complexity while providing a simple, well-defined interface. Imagine a restaurant, where you look at a menu (list of available API operations), and request the food of your choice through a waiter in a standard format. The waiter is an API which takes your request to the kitchen (server where the business function is deployed). The kitchen prepares your meal (you don’t really care to know all the nitty gritty details), the waiter delivers the food (response) which you pay for at the end. This whole contract is broadly understood and everybody knows their part and the whole transaction goes smoothly without any exceptions most of the time. There are instances where either a certain item on the menu is not available (404 NOT FOUND) or you have a custom request which the kitchen cannot fulfill (400 BAD REQUEST), or some unexpected problem happens (5XX SYSTEM ERROR).
APIs also provide a common mechanism for Inter Process Communication where multiple business/technical functions can interact with each other to perform an overall function.
Evolution of APIs
Despite not being called APIs at first, the concept of APIs has been around since the dawn of computer science. The methods of implementing APIs have evolved continuously since then. In pre-internet times, APIs were more of a contract between co-located or closely located small systems. When the internet was invented, geo boundaries began to dissolve, making data sharing and syndicating possible without concern for organizational, geographic or domain boundaries. API implementation methods have been evolving for wide adoption, interoperability, reliability, performance, and scalability.
In its first iteration of API runtime and data exchange standards, SOAP (Simple Objects Access Protocol) provided a specification to exchange structured data in XML format. This enabled the standardization of XML based data exchange for better interoperability of APIs over the web. The SOAP protocol supports both high-level and low-level transfer protocols. For instance, SOAP allows for messaging via TCP, SMTP for electronic mail transmission, FTP, and any other transfer method that supports text data exchange. SOAP was primarily designed to work with HTTP but there may be scenarios that will benefit from SOAP versatility in supported protocols. SOAP works only with XML and has some challenges due to heavier message structure, which requires larger bandwidthBandwidth is the maximum rate of data transfer across a given path. Bandwidth may be characterized as network bandwidth, data bandwidth, or digital bandwidth. It generally refers to the size of the pipe and the speed that carries the data back and forth, not necessarily the volume of traffic that passes through. More. Being protocol-based, building SOAP API servers requires knowledge and understanding of all protocols you may use with it and hence has a longer harder learning curve. A rigid SOAP schema makes it difficult to add or remove message properties between server and client, which slows adoption and makes updating requests and responses a pain. Due to these reasons, SOAP was complex to build, complex to use, and almost impossible to debug.
REST was designed by Roy Fielding in his 2000 PhD dissertation “Architectural Styles and the Design of Network-based Software Architectures“, with an objective to create a standard to enable server-to-server communication. Here’s what he had in his dissertation:
I had comments from well over 500 developers, many of whom were distinguished engineers with decades of experience, and I had to explain everything from the most abstract notions of Web interaction to the finest details of HTTP syntax. That process honed my model down to a core set of principles, properties, and constraints that are now called REST.
– Uniform interface. This means we always use HTTP verbs (GET, PUT, POST, DELETE). We always use URIs as our resources. And we always get an HTTP response with a status and a body.
– Stateless. This means each request is self-descriptive, and has enough context for the server to process that message.
– Client-server. There has to be clear boundaries between roles of the two systems. One server, operationally, has to function as the server that is being called, and the other has to function as the one making the requests.
– Cacheable. Unless denoted, a client can cache any representation. This is possible thanks to the statelessness—every representation is self-descriptive.
With REST, Roy Fielding provided the world a consistent way for the softwares to communicate.
With the increasing demand of public APIs, developers started providing services via APIs and also were able to add functionality to their applications easily and quickly by leveraging existing code, whether it was REST APIs provided by giants like AWS, and Google or by other developers as open-source software or services. The API directory, ProgrammableWeb, had just 54 APIs in 2005 and the list has now grown to more than 24000 APIs. With the growth of APIs, new formats have gained popularity as well. While REST is still the most popular format, other formats such as GraphQL (popular for flexibility) and gRPC (popular for performance) are also seeing increased market adoption.
GraphQL was originally developed by Facebook developers in 2012 and was publicly released in 2015. In contrast to REST APIs, where you may need to call many endpoints to gather all the data needed for a view, API developers use GraphQL to build a unified data graph that can then be queried by API consumers for all or parts of the data. The ability of clients to query the data they want, all in one call, is what GraphQL provides.
gRPC is based on Stubby, the API technology that Google has used internally for more than a decade. gRPC was released publicly after the HTTP/2 specification was published. gRPC provides an API-first framework which allows developers to leverage performance improvements and capabilities of HTTP/2. gRPC makes API-first and design-first as the only way to create APIs enhancing the quality and interoperability of APIs. gRPC also has proven to be a great method for performant, reliable inter-process communication between microservices.
WIth REST, the design-first approach for building API was not implicit but Open API Specification, previously known as Swagger, provides a common design-first approach to building APIs which are easy to integrate and enable API economy.
The OpenAPI Specification defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
An OpenAPI definition can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.
The choice between REST (Open API), GraphQL, gRPC should be driven by application requirements around data, consumption, performance, and scalability.
Alef’s Open Edge APIs
Alef provides Open APIs for enterprises to create, connect, and manage their private mobile networks with the ability to securely and seamlessly run their business workflows on near-prem edges.
With Alef’s Edge API Platform, enterprises don’t have to worry about the complexity of onboarding and maintaining core and they have the ability to orchestrate their business workflows at edge.
Alef’s Edge APIs provide easy to set up workflow distribution between edge points and cloud. Where Edge provides low latency and decentralization, cloud has overcome the limitations of power, space and cooling and provides close to unlimited compute and storage, the Alef’s Edge Platform enables the enterprises to leverage the best of both worlds (edge and cloud) to seamlessly orchestrate and distribute their business workflows.
Alef…as a Service (aaS) suite with its open APIs provide:
- APIs that enable enterprises to create, connect, and manage private mobile wireless networks within enterprise IT.
- Mobile Network as a Service (MNaaSMobile Network as a Service - An API based system that allows you to start your own private LTE network without knowledge of 3GPP standards. More) that provides industry standard reliability of 99.999% (by end of 2022), reliable wireless mobility for the private networks within enterprise and latencyTime required to send data over two points in a network. More <= 50 ms between enterprise site and near-prem edge
- Connectivity to public clouds that is low-latency and reliable
- Business processes that can be orchestrated and run/distributed between near, far, and public clouds
- Easy to manage subscriberAn individual enterprise user that uses a physical SIM or an eSIM in the user equipment/mobile device. More lifecycle and QoSQuality of Service - Use of mechanisms or technologies that work on a network to control traffic and ensure the performance of critical applications with limited network capacity. It enables organizations to adjust their overall network traffic by prioritizing specific high-performance applications. Learn More More without worrying about internals of integrating and maintaining the core (EPCEvolved Packet Core - The framework that converges voice and data on a 4G LTE network. This allows operators to deploy and operate one packet network for 2G, 3G, WLAN, WiMax, LTE and fixed access (Ethernet, DSL, cable and fiber) More).
Our open APIs will enable enterprises to integrate these capabilities seamlessly in their IT systems so that they don’t have to worry about external hardware and software maintenance.
Through simple Open APIs, AEP abstracts the complexity of network configuration and maintenance to provide a Service and Management layer for Enterprise IT. These APIs provide an easy mechanism for enterprises to integrate the management of AEP into their existing IT system as needed. APIs provide all the necessary functions with the freedom and power in the hands of the enterprise on how to configure and use the capabilities within or outside their existing IT systems.
Alef follows API-first with design-first principles where APIs are “first-class citizens” and are treated as Products, which provide great DX by having Industry standard API specification to create API definition first and then write the code for the API. APIs follow a consistent style guide which defines standardized API status codes, versioning, error handling, etc. API documentation is generated and maintained as primary product documentation. The API server hosting all our APIs have clear functional and non-functional requirements covering design, development, discovery, operations, security, and governance.