Key Points

Resources

Key Concepts

API architecture models

Muhammed Gaafa

https://www.linkedin.com/feed/update/urn:li:activity:7095679969976025088/

API architectural style :

1. REST (Representational State Transfer):
   A champion of simplicity and ubiquity, REST is an architectural style that primarily leverages HTTP methods. It enables easy interaction with resources, making it a go-to pattern for a multitude of applications and modern APIs.

2. SOAP (Simple Object Access Protocol):
   SOAP, a heavyweight contender in the API arena, thrives on complexity and power. It employs XML for defining structured communication. Although requiring a SOAP client and server, it compensates with its strength and robustness, much like a well-built off-road vehicle tackling rugged terrains.

3. GraphQL:
   A rising star in the API cosmos, GraphQL offers flexibility and precision. It lets clients ask for exactly what they need, reducing redundancy, and improving performance. Think of it as a personal shopper - you get just what you asked for, nothing more, nothing less.

4. gRPC (Google Remote Procedure Call):
   gRPC is the speedster of the API universe. Running on HTTP/2 and using binary data, it's all about performance and speed, especially for microservices architectures. It's like a high-speed train, ensuring quick and reliable communication.

5. WebSockets:
   If real-time and bi-directional communication is what you need, WebSockets are the answer. Ideal for chat applications, live streaming, and real-time data exchange, it's like having an open telephone line between clients and servers.

6. Webhooks:
   Webhooks are the town criers of the digital world. They notify clients when certain server-side events occur, making them perfect for event-driven architectures. Imagine them as your personal alert system, keeping you informed of what matters.

7. MQTT (Message Queuing Telemetry Transport):
   MQTT is a lightweight messenger, designed specifically for environments with limited resources, low bandwidth, and unreliable networks. Picture it as a postal worker determined to deliver your mail, come rain or shine.

8. AMQP (Advanced Message Queuing Protocol):
   A robust and standardized protocol, AMQP excels in middleware environments with its reliable messaging capabilities. It's like a well-oiled assembly line, efficiently moving messages where they need to go.
   
   my adds

9. Apache Pulsar
   Cloud-Native, Distributed Messaging and Streaming
   Apache® Pulsar™ is an open-source, distributed messaging and streaming platform built for the cloud with multi-tenancy with resource separation and access control, geo-replication across regions, tiered storage

10. Apache Kafka
    Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. Supports pub / sub and message broker features.

Which API architectural style should you use?

The best API architectural style for a particular application will depend on the specific requirements of the application, such as  -

1. The type of data that will be exchanged between the API and the client

2. The performance requirements of the API

3. The security requirements of the API

4. The scalability requirements of the API

Once you have considered these factors, you can start to narrow down your choices and choose the API architectural style that is best suited for your application.
---------

Open

6 Common API Architectures

https://www.linkedin.com/posts/reillychristian_i-cant-remember-where-i-saw-this-but-its-activity-7113504151845642240-cG8X?utm_source=share&utm_medium=member_desktop

I can't remember where I saw this, but it's brilliant. With the advent of LLMs and the explosion of SaaS apps, APIs are going to continue to be more and more important.

Open

Related Services for API Solutions

Apache Spark™
is a multi-language engine for executing data engineering, data science, and machine learning on single-node machines or clusters.

API Gateways

• API gateway connects client app requests to API services returning responses ( synchronous or asynchronous )

• Provides dynamic routing, analytics, security protections, session management

• Loosely couples access from internal, external clients to APIs using protocols: SOAP, REST, RPC

• External and internal business systems integrate microservices and data in workflows easily and efficiently

marutitech on API Gateways

https://marutitech.com/api-gateway-in-microservices-architecture/

Open

API Gateway is a reverse proxy that accepts all API calls, applies various services to fulfill the calls, and returns the appropriate output. In simple words, an API gateway is a server that summarizes the internal system architecture of the application. 

the microservices architecture pattern, which are as given below:

• API gateway helps to stop exposing internal concerns to external clients

• API gateway helps to provide additional security to your microservices 

• API gateway helps to merge the communication protocols

• As you have studied, API gateway helps to decrease the complexity of microservices, eventually improving the efficiency of the application.

• API gateway helps separate the microservice API and other external APIs to virtualize the design requirements and testing. 

The below table shows a better representation of the difference between Microservices API Gateway vs. Traditional API Gateways.

The API Gateway and the API microservice architecture can simplify client calls for information from multiple sources

Convert API COE to API Platform team?

API center-of-excellence teams intended to increase API quality; however, COEs can often become bureaucratic bottlenecks. Software engineering leaders responsible for API strategies should create platform teams that support the consistent and rapid delivery of APIs and ensure API excellence.

Key Findings

• Software engineering leaders responsible for API strategies often struggle to organize teams that are capable of realizing and maximizing the benefits of this technology. This leads to inconsistent and immature API delivery.

• While centralized API quality team structures — such as centers of excellence — enforce consistency and consolidate expertise, they often become bottlenecks to delivery.

• Allowing development teams to have complete autonomy runs the risk of proliferating technologies and design practices, making governance and value measurement difficult and inconsistent.

Organization Issues

Centrailzed ? consistency, efficiency ok << fit to purpose solutions difficult

Decentralized ? consistency, efficiency, redundancy challenges << fit to purpose ok

Federated? addresses consistency, efficiency, fit to purpose, dependencies, adaptability

Recommendations

Software engineering leaders in charge of API strategies and delivery should:

• Create a federated API platform team in charge of API strategy. This team must define governance, operate the organization’s API management platform and create a community of practice to improve the maturity and consistency of API designs.

• Create the API product manager role, in charge of overseeing the strategy and roadmap for APIs managed as products for internal or external consumers. This role should prevent API delivery bottlenecks and be part of the API platform team.

• Provide adaptive governance capabilities that deliver the right governance outcomes across control, agility and autonomy against API producer and consumer needs.

Opportunities

https://www.linkedin.com/posts/rajkgrover_api-apimanagement-apis-activity-7039554894533435392-9Le2?utm_source=share&utm_medium=member_desktop

API Life Cycle

https://www.ibm.com/cloud/blog/api-gateway

phases of the API lifecycle are creating (building and documenting the API), controlling (applying security) and consuming (publishing and monetizing your APIs). API gateways fall under the control phase of the API lifecycle — they secure APIs and keep data safe.

Benefits of API gateways

IBM > https://www.ibm.com/cloud/blog/api-gateway

Adding one or more API gateways to your microservice applications provides many benefits:

• Microservices security: An API gateway puts a barrier in front of an application’s backend, making it more secure. It means an application’s endpoints are not exposed; therefore, there’s less threat of attack. A company can also use HTTPS for additional security or HTTP encrypted with SSL, which improves performance.

• API authentication: An API gateway provides another security layer that protects against mistakes, hacks and data breaches by authenticating API calls. Authentication and authorization can include antivirus scanning, decryption and encryption, token translation, validation and other security functions.

• Input validation: Input validation ensures an API request has all the necessary information in the correct format before the gateway passes it along to a microservice. If something is missing or wrong, the gateway rejects the request. When it’s validated as being correct, the gateway sends the request.

• Faster response times: Because an API gateway sends requests directly to the right services, there are fewer roundtrips and less traffic, reduced latency and better performance overall, which means an application provides an improved user experience.

• Microservices load balancing: An API gateway keeps track of requests sent to different microservices, balances the load between nodes for efficiency and ensures the application remains available. This load balancing is critical when high traffic levels are expected — such as during a Black Friday sale or new product launch — to prevent spikes or denial-of-service events.

• Rate limiting: Rate limiting means an API gateway monitors traffic coming in from all sources and limits how many API requests a client (or malicious bot) can make in a specific time period — per second, or per day, week or month — to protect the system from being flooded with requests and possibly crashing.

• Billing for microservices: Some businesses monetize some of their APIs by offering a service to consumers or other companies. The API gateway handles traffic, monitors usage for specific products or services and sends pricing information to a connected billing system. There are different types of direct monetization, including users paying as they access a service or resource, for a certain number of services or via tiers (where different services are provided at different levels). Other APIs share revenue with consumers through ad revenue share, affiliate marketing or credits to a consumer’s bill.

• Microservices caching: API gateways can help optimize API calls, such as with microservices caching. Caching responses to API calls can help avoid unnecessary load on backend services. The cached responses can be used when similar requests are received, improving performance and decreasing cost.

• Monitoring and tracking apps’ analytics: Since an API gateway controls all of an application’s inbound traffic, it’s straightforward to have the software monitor and produce reports about visibility, trends and other insights about API usage. The gateway software can also create traffic logs that help an API provider understand and fix infrastructure problems.

• Extending legacy apps: Businesses still use legacy applications that contain essential data, perform significant functions and provide value, but the apps were not written for APIs. Such older technology can have trouble handling the increasing numbers of calls from newer technologies, such as mobile, SaaS or IoT apps. They can also be hard to access. Instead of taking on a complicated cloud migration, a DevOps team can add API functionality — including benefits like rate limiting and throttling — to help modernize and extend the functionality of a legacy application.

• Maintaining APIs: When APIs need to be updated, typically many clients may have operational dependencies running the existing APIs. The gateway provides separation of the client solutions from the server APIs. This can allow operations to deploy 2 versions of APIs and let clients choose when they are ready to consume the new APIs. When a client is ready for the new APIs, the gateway config just routes the API requests to the new API version

API Service Capability Architecture Model

https://www.linkedin.com/posts/transformpartner_api-capability-apiplatform-activity-7031875497991024640-lF5A?utm_source=share&utm_medium=member_desktop

The following capability model identifies some of the capabilities expected of a 3rd-generation #APIplatform. Although not all of the capabilities are core to the platform, related capabilities have been included because they're considered critical in order to have an end-to-end solution. The use of models such as this one is highly recommended as it provides a structured framework for deciding what technologies can be adopted to realize each capability.
 
As it can be noted from the diagram, #APIgateway play a central role, not only because they are the engines that run the #APIs, but also because they are the point of entry to information assets and where policies are applied. If APIs are doorways to information, API gateways surely are the doors.
Although not explicitly shown in the model, there are some fundamental capabilities that set 3rd-generation API gateways apart from1st- and 2nd-generation ones:
 

• Lightweight: Non-monolithic, appliance-less, ESB-less. They should be lightweight and very easy to implement (anywhere) -- ideally, using containers.

• Self-sufficient: It should be their responsibility retrieve APIs, policies and even system patches from a central management unit.

• Microservice oriented: It should be possible to:

• Be stateless. No state should be managed for any transaction.

• Implement services in any language and or technology of choice.

• Elastically scale gateways in or out based on different conditions.

• Implement API load-balancers by integrating with registries (e.g., Consul, Eureka, etc.) and dynamically determining active service endpoints and routes intelligently.

• Prevent developers from adding logic into the gateways by not providing capabilities that don't belong on a gateway.

 
Source: Oracle

Challenges

Challenges of API gateways

IBM > https://www.ibm.com/cloud/blog/api-gateway

While there are many benefits to adding an API gateway, there can also be challenges:

• Response time: While latency and response time are often decreased due to requests traveling more efficiently, the additional step of a request passing through an API gateway can potentially add to response time.

• Dependencies: Anytime a business adds, changes or removes a microservice, it must update its API gateway. That can be challenging with an application that has evolved from having just a few microservices to encompassing many. However, creating API design rules can help with this.

• Complexity: Routing logic can make communication with microservices more complex. The API gateway is another system that must be developed, deployed and maintained.

• Security: Because an API gateway touches many areas of an enterprise’s systems, its compromise can seriously impact an application’s safety. 

• Reliability: If there’s only one API gateway and it goes down, the whole application becomes unavailable. Creating multiple API gateways and using load balancers can help avoid this situation.

Harvard study on Web API Platform business model keys

https://hbr-org.cdn.ampproject.org/c/s/hbr.org/amp/2019/05/a-study-of-more-than-250-platforms-reveals-why-most-fail

https://drive.google.com/file/d/1tinu5QbB4uWk229grRGaIM7LmR2UUlCE/view?usp=sharing

• innovation - host 3rd party apps ( eg wordpress etc

• transactions - host company apps

 In our analysis of data going back 20 years, we also identified 43 publicly-listed platform companies in the Forbes Global 2000. These platforms generated the same level of annual revenues (about $4.5 billion) as their non-platform counterparts, but used half the number of employees. They also had twice the operating profits and much higher market values and growth rates.

To understand why and how platforms fail, we tried to identify as many failed American platforms as possible over the last twenty years that competed with the 43 successful platforms. The 209 failures allowed us to extract some general lessons about why platforms struggle.

collapsed within 2-3 years because they did not have enough users or funding ( especially if standalone company )

Acquired firms, which generally had stronger balance sheets, were capable of fighting longer (averaged 7.4 years), while firms that were part of larger entities were just average in length of survival

Key failure issues

common mistakes into four categories:

1. (1) mispricing on one side of the market, (

2. 2) failure to develop trust with users and partners, (

3. 3) prematurely dismissing the competition, and

4. (4) entering too late.

pricing decisions

A platform often requires underwriting one side of the market to encourage the other side to participate.  But knowing which side should get charged and which side should get subsidized may be the single most important strategic decision for any platform.

throw commonsense pricing out the window when two or more platforms are racing to create a network effect.

platform network trust models key

Platforms also require two or more parties, who may or may not know each other, to connect. Therefore, building trust is essential; this is typically done through rating systems, payment mechanisms, or insurance.

go beyond digital trust > build relationship trust ( reputation ) > service & support > governance trust with escrow transactions ( both parties acknowledge completion - restock fee option) > measure and communicate trust results transparently

taking market leadership for granted

 overconfidence and arrogance, to name a few misdirected traits, can produce spectacular failures - MS Internet Explorer failure

late entry fails

mistiming the market. The smartphone market illustrates how great products plus all the resources in the world can still lead to failure when entry is too late. Here again, Microsoft was the poster child for failure

Keys to focus on

Planning around network effects

platforms are ultimately driven by network effects, getting the prices right and identifying which sides to subsidize remain the biggest challenges.

Trust is more than digital trust

put trust front and center. Asking customers or suppliers to take a leap of faith, without history and without prior connections to the other side of a market, is usually asking too much of any platform business. 

go beyond digital trust > build relationship trust ( reputation ) > service & support > governance trust with escrow transactions ( both parties acknowledge completion - restock fee option) > measure and communicate trust results transparently

Solutions

https://www.ibm.com/opensource/open/projects/api-microgateway/ IBM Nodejs open source gateway software for developers

An open-source API gateway lets DevOps teams create new API sources without writing code. Some of the benefits of an open-source API gateway include letting a company start small and scale up fast, allowing the flexibility to innovate and change quickly and providing transparency for users.

Service Mesh - Istio

https://www.ibm.com/cloud/learn/istio

Istio is a configurable, open source service-mesh layer that connects, monitors, and secures the containers in a Kubernetes cluster. At this writing, Istio works natively with Kubernetes only, but its open source nature makes it possible for anyone to write extensions enabling Istio to run on any cluster software. Today, we'll focus on using Istio with Kubernetes, its most popular use case.

Kubernetes is a container orchestration tool, and one core unit of Kubernetes is a node. A node consists of one or more containers, along with file systems or other components. A microservices architecture might have a dozen different nodes, each representing different microservices. Kubernetes manages availability and resource consumption of nodes, adding pods as demand increases with the pod autoscaler. Istio injects additional containers into the pod to add security, management, and monitoring.

Because it is open source, Istio can run on any public cloud provider that supports it and any private cloud with willing administrators.

Open Insurance Market built on APIs

https://openinsurance.io/tech-lab/creating-an-insurance-api-platform/

api-platform-openinsurance.io-Creating an Insurance API Platform.pdf link

Open

file

OpenInsurance API Standards

https://openinsurance.io/standards/

Challenge

Encourage entrepreneurs and third party developers to build apps on top of open insurance APIs.

Purpose of a common data standard
This is the first step towards producing a common API spec.
Specification for the definition of data properties, structures, relationships, technical names, and data types.
A domain model that is technology-agnostic and in comprehensible business terms.
Defines requirements and common methodology.
A foundation for managing data quality and integrity.
A framework for database design

The OpenInsurance Standard Definitions workbook

This is NOT an API spec but IS a model for input to an API

< Better done as UML design that can generate an API Spec and Code using Swagger >

The OpenInsurance BluePrint

https://openinsurance.io/open-insurance-blueprint/

Next Steps