APIs and Microservices

 UNDERSTANDING WEB APIs

What are web APIs?

As a review, an application programming interface (API) specifies how software components and systems should interact with each other. Web APIs extend this interaction beyond a single application by using HTTP, the language of the web, as the network protocol. A web API doesn’t have to be RESTful. It doesn’t have to use SOAP. It doesn’t have to use JSON or XML or OAuth or be built in a specific programming language or framework. It doesn’t have to have pretty URLs. Web APIs may exhibit some, all, or none of these traits. The only requirement for a web API is that it allows one program or software component to interact with another in a repeatable way over HTTP.

image.pngDiagram of a simple web-based application that retrieves data from a database via an API.

Effective API programs help to break down these siloed systems by decomposing them into smaller areas of concern (sometimes referred to as “bounded contexts”). These areas offer a clear API that provides the capabilities and data for a specific business concern. Solutions are then built on these APIs to solve the needs of the internal business, partners, app developers, and third-party solution providers

API STYLES
The three most common API styles today are REST, GraphQL, and gRPC. Each one has strengths and weaknesses, summarized here:
REST
stands for Representational State Transfer, an architectural style detailed by Dr. Roy Fielding in a 2000 dissertation that outlines the architectural decisions and constraints applied to the HTTP specification. While not a standard, it has been used to provide an architectural guidepost for designing web-based APIs. Over time, REST has come to stand for some as JSON over HTTP, commonly through the create, read, update, and delete (CRUD) pattern. While this may be a common pattern, there are a variety of approaches available to building web-based APIs over HTTP. REST-based APIs are easily managed because each capability has its own URL that may be secured and monitored through API Management (APIM), as discussed later. Therefore, offering a REST-based API is a great starting point, allowing any application or automation script to interact with your API over HTTP.

GraphQL
originated at Facebook as a method of optimizing HTTP-based interactions between their mobile app and their graph-based back end. It has since become a common choice by front-end developers that desire a consistent way of expressing queries for the exact data desired. It is also used to aggregate multiple back-end REST APIs into a single request. GraphQL requests resemble SOAPbased remote procedure call (RPC) requests, with a single endpoint that accepts a specific request format. They are therefore more difficult to secure, monitor, and manage because they are managed as a single URL by APIM.

gRPC
started at Google as a high-performance way to send RPC requests between services. gRPC is built on the newer HTTP/2 specification, which supports performance improvements and multiplexing communications. The result is a protocol optimized for service-to-service communications within a microservice-based architecture
Organizations have multiple options for exposing their API-based capabilities. These choices allow API platforms to address the specific needs of developers by offering one or more API styles. For most organizations, using REST as a foundational API style is wise because it has an approachable management, security, and tooling history. gRPC may be used to optimize internal service-to-service communication where appropriate. GraphQL is a good choice in addition to REST for reporting and front-end APIs that require optimizations for the customer experience.

PLATFORM EVENT NOTIFICATIONS
Platform event notifications create extensibility. One of the most powerful elements of an API platform is event notification support. For every API capability that creates or modifies data, there is at least one event that another system or solution may be interested in receiving a notification about when it occurs. Events allow solutions to be built on top of the platform without the platform knowing they exist. These emerging solutions are notified when state changes occur. It also removes the need for systems to constantly poll an API to see if any data has changed, using resources more efficiently. Those familiar with event-driven architectures (EDAs) know the power of events for integrating services and scaling systems. Exposing some internal events or emitting coarse-grained business events as part of an API platform reduces system-to-system coupling and creates opportunities for innovation in an agile way.

DATA STREAMS
Data streaming provides continuous, ordered delivery of atomic messages that represent state change in data. Unlike web APIs that deliver data and behavior, data streaming focuses on raw data.
Message streams are a recent addition to the API platform. They are used to enforce data governance and data lineage requirements of regulated businesses. In addition, they are becoming the preferred way for data analysis and machine learning solutions that need to act on data as it becomes available, rather than the more traditional batch-based approach through technologies such as Hadoop.

image.png
Being able to act on data in real time is a key focus of a maturing API platform. By being able to scale how you use your own data, you will be able to analyze and act in a more agile way

THE EMERGENCE OF MICROSERVICES
Over the last decade, we have seen new development frameworks emerge to make it easier than ever to build and deploy web-based applications. The downside of these frameworks is that they rarely encourage modular design. The result is quick development at the start of a new project, but over time complexity increases beyond the ability of the framework to maintain the efficiencies it first enabled.
At the same time, containerization tools such as Docker and orchestration layers such as Kubernetes have emerged. These tools encourage developers to easily break unwieldy applications into smaller components and deploy them in a predictable way. The intersection of these circumstances has led to a renewed interest in modular software design. Unlike past modular efforts through component-based development, we are seeing these modules built as services and externalized on the network. This has resulted in the rise of microservices.
Like many terms in the software industry, “microservices” brings to mind a variety of things. Some think of microservices as small bits of code that offer a web-based API. Others think of microservices as a promise to speed up their struggling development teams. Both of these things are true, but there is more to microservices than many realize. A microservice is a self-contained, independently deployable unit of code that focuses on doing one thing well. Microservices have no specific line count, contrary to what some may believe.
A microservice architecture exhibits the following traits:
• Applies bounded contexts to limit cognitive load.
• Deploys independently via CI/CD automation.
• Enables replaceability and experimentation by limiting the scope of each service.
• Encourages right-sizing through the continual splitting and recombination of services.
• Manages its own data sources and does not share them with other services.

MICROSERVICE ARCHITECTURE
A MSA is made up of a combination of API-based services and event- or message-driven services. A common practice is to include front-end orchestration APIs that make calls to one or more microservices. This enables organizations to offer stable contracts through the orchestration APIs, while replacing or splitting microservices behind the scenes and with no impact to API consumers.
image.png
API MANAGEMENT AND SECURITY
API Management (APIM) layers accelerate the deployment, monitoring, security, versioning, and sharing of APIs. They are often deployed as a reverse proxy, intercepting all incoming API request traffic and applying policies to determine if requests are authorized to be routed to the API.
Additionally, APIM enforces rate limits to prevent unlimited API usage, helps ensure security through API tokens and/or OAuth 2, and protects against a number of attack vectors. While some offer identity management as a built-in feature, most organizations will configure APIM to work with a third-party identity provider to offload user management and authentication.
Identity provider
An identity provider (abbreviated IdP) creates, maintains, and manages identity and access information for your API. They also provide authentication services to your APIM and support single sign-on (SSO) through technologies such as Security Assertion Markup Language (SAML). Some IdPs offer OpenID Connect (OIDC) support, which extends OAuth 2.0 with additional authorization support using web APIs and JSON identity tokens.

CONTENT DISTRIBUTION NETWORK
A content distribution network (CDN) is a distributed cache at the edge of the internet that helps to reduce the load on origin servers. This helps cacheable API responses to be returned to web or mobile apps quicker because the content is often closer to the device than the origin servers. CDNs also offer additional protection from distributed denial-of-service (DDoS) attacks by monitoring layer 3 and layer 4 traffic, detecting problems, and preventing those problems from impacting customers, partners, and internal systems.

API DEFINITION AND DOCUMENTATION
Effective communication is a critical factor for API adoption. In fact, your documentation is the primary method for communicating with developers on how to use the API. Your API documentation is your API’s user interface.
API documentation was previously captured in a static document using HTML or PDF, but new options are now available. Tools such as Swagger, RAML, and Blueprint are just a few of the formats available to capture the definition of your API in a machine-readable format. These formats support the generation of reference documentation for your API.

API DEVELOPMENT STRATEGY
APIs extend beyond a set of technologies with developer interest. They power customer experience, business relationships, and internal innovation. A clear API strategy transforms your data and processes into digital capabilities with a programmable interface.
Designing an API design-first process
Too often, API design is either ignored or rushed and therefore fails to take advantage of the opportunity to learn and improve on an API design before release. Taking an API design-first approach allows for incorporating feedback before it is released, preventing the need for breaking changes immediately after release. An API design-first approach starts by identifying the capabilities to be delivered and then moves toward an API design to meet those capabilities. All this occurs before a line of code is written. Although this may seem like a waterfall approach, it isn’t. Instead, it is the application of the Agile Manifesto principle of combining business and technology into small iterations that deliver business value.
The process consists of the following steps, executed in parallel when possible:

Discover the capabilities that need to be delivered. Focus on behavior and desired outcomes first, before focusing on the code.
Model and design the API. Transform the desired capabilities into a resource-based approach using the power of HTTP.
Document the initial API design. The documentation should provide enough understanding to demonstrate common use cases.
Seek feedback from stakeholders. Use feedback to validate that the API design meets stakeholder needs.
Update the API design. Incorporate feedback as appropriate into the design before code has been be updated. Repeat steps 1 through 4 as often as needed to refine the API design.
Produce a mock version of the API. As the design begins to take shape, use the captured design definition, typically using the OpenAPI format, for your stakeholders to review.
Release the implemented API as a preview release. During this preview release, additional insights and incorrect design assumptions will emerge. Make necessary changes before officially releasing the API into production.
Promote the release to production. Once the preview release meets the needs of stakeholders, release the API to production. At this point, breaking changes are not allowed.
image.png


API LIFE CYCLE
An API program should establish a clear and comprehensive API life cycle. The seven common stages for an API life cycle are:

Discover Identify new API capabilities as needs emerge from stakeholders.
Design Refine those needs with the stakeholders, identify capability requirements, and design the API accordingly.
Deliver Implement, test, and verify that the new capabilities meet stakeholder expectations.
Release Deploy, monitor, and manage the API at runtime.
Share Inform your stakeholders and other developers of the new capabilities.
Enhance Incorporate consumer feedback and use proper versioning techniques to enhance the API without disrupting existing consumers.
Retire Inform consumers of any plans to stop supporting an existing API, migrate consumers to a new API (if available), and retire the API.
DEFINING AN API TEST STRATEGY
When building an API, a proper test strategy ensures that your API both works correctly and meets the promises of its definition. A complete API testing strategy covers the code, the API functionality, API contract testing, and acceptance testing.
Unit testing
focuses on whether the code that powers your API is working properly. It helps to reproduce a discovered bug, verify the bug is fixed, and prevent regression of the bug as the code continues to change and evolve.
Functional testing
verifies that each API endpoint meets the expected behavior. Functional tests should exercise each endpoint for success and error cases to ensure that the API was coded defensively in the face of bad or malicious client code.
Contract testing
ensures that the implementation of the API matches the specification. Compare your runtime API request/response traffic against your API definitions (typically in OpenAPI, API Blueprint, or RAML format), reporting anything that deviates from the expected contract.
Acceptance testing
executes a series of predetermined paths that best represent the kinds of interactions your end users will have with your API, verifying that a specific end state is achieved.

MONITORING YOUR APIS
Monitoring today’s robust applications requires more than just making sure your processes are running. It requires tracing an incoming web request across all the endpoints and services that support that request. Observability ensures that you can detect when recent deployments result in an increased number of errors.

CONCLUSION
While it may be challenging at times to launch and sustain an API program, it is ultimately rewarding when you see the organizational shift from a set of ad hoc APIs to a healthy API program. By incorporating these practices into your API program, you will create a predictable API design and delivery process, alongside a complete API architecture that ensures your APIs are monitored, managed, and secure.

Comments

Popular posts from this blog

Interview Questions to Ask the Employer

Place .NET DLL in GAC

Windows Communication Foundation - FAQ