API Lifecycle
These are the 68 steps in a modern API lifecycle I am keeping track of, trying to understand how APIs are being delivered, from define to deprecation.
|
StartThe API journey is rarely a linear thing, with a clear start or finish. However, to help understand the many steps in a modern API lifecycle, it helps to have a place to start, and a place to finish. This is the beginning of your journey to better understand the numerous stops that exist along a modern API lifecycle... |
|||||||||
|
DefinitionsFrom the simplest definition of what a service does, all the way to the complete OpenAPI definition for each service. These are the artifacts that will guide each service through every step of the API lifecycle. API definitions are not just for documentation, or for generating code, they define the contract that a service delivers. |
|||||||||
|
DesignThe consistent design of each service leverage existing patterns, as well as focusing on the web to deliver services. Thinking critically, consistently, and practically about how we design the APIs, and evolve this practice with each version of our service. |
|||||||||
|
CachingWhat caching exists at the server, CDN, and DNS layers for each service to provide a higher level of performance? |
|||||||||
|
DeploymentThe myriad of ways in which APIs are deployed from existing backend system, databases, filesystems, and proxying, and building facades of older legacy, or 3rd party services. There are often too many ways to deploy an API, making it a difficult area to easily bring into focus and lead developers and business stakeholders through. |
|||||||||
|
VirtualizationDetails how how services and their underlying data are mocked, virtualized, sandboxed, and made available for non-production usage. |
|||||||||
|
AuthenticationWhat is involved with authentication across all services, including key-based approaches, basic authentication, JWT, and OAuth solutions. |
|||||||||
|
DependenciesIdentifying all backend service, code and infrastructure dependencies present for each service. |
|||||||||
|
DNSThe domain addressing being used for routing, management and auditing of all service traffic, opening up this layer of the stack to be accessible as part of the API lifecycle. |
|||||||||
|
ManagementInformation about how services are composed, limited, measured, reported upon, and managed consistently across all services, providing a consistent definition to how services get managed. |
|||||||||
|
PortalThe strategy for how all services are required to be published to one or many public, private, and partner developer portals. Providing a single location where all services can be accessed, with accompanying documentation and other essential building blocks of API operations. |
|||||||||
|
DocumentationThe requirements for what documentation is expected as part of each service presence, defining what the services delivers. |
|||||||||
|
LoggingWhat is being logged as part of service operations, and what is required to participate in overall logging strategy? |
|||||||||
|
SupportRelevant support channels, points of contact, and best practices for receiving support as an API consumer. |
|||||||||
|
CommunicationsInformation about the communication strategy around each service, and how blogs, social, and other channels should be leveraged. |
|||||||||
|
Road MapDetails on a services road map, and what the future will hold, providing individual service, as well as larger organizational details on what is next. |
|||||||||
|
IssuesExpectations, communications, and transparency around what the current bugs, issues, and other active problems exist on a platform. |
|||||||||
|
Change LogTranslating the road map, and issues into a log of activity that has occurred for each service, providing a history of the service. |
|||||||||
|
VersioningPlan for handling changes, and the inevitable evolution of each service, its definitions, and supporting code, establishing common and consistent approaches to approaching and communicating around the versioning of everything service related. |
|||||||||
|
TestingThe tactical, as well as strategic testing that is involved with each service, ensuring it is meeting service level agreements, and that API requests and responses are operating as expected. |
|||||||||
|
PerformanceHow is the performance of each service measured and report upon, providing a benchmark for the quality of service. |
|||||||||
|
ObservabilityWhat does observability of the service look like, providing transparency and accountability using all of its existing outputs? |
|||||||||
|
EncryptionDetails regarding what is expected regarding encryption on disk, as well as in transport for each service. |
|||||||||
|
SecurityDetailed strategy and processes regarding how each service is secured on a regular basis as part of operations. |
|||||||||
|
Terms of ServiceConsiderations, and legal requirements applied to each service as part of the overall, or individual terms of services. |
|||||||||
|
PrivacyDetails regarding the privacy of platform owners, developers, and end users as it pertains to service usage. |
|||||||||
|
Service Level AgreementsDetails regarding what service levels are required to be met when it comes to partner and public engagements. |
|||||||||
|
LicensingInformation about backend server code, API surface area, data, and client licensing in play. |
|||||||||
|
BrandingWhat branding requirements are in place for the platforms and its partners when it comes to the service, and what is expected of consumers when it comes to supporting the branding of the platform. |
|||||||||
|
RegulationsInformation regarding regulations in place that effect service operations, and are required as part of its usage. |
|||||||||
|
DiscoveryHow are services catalogued and made discoverable, making them accessible to other systems, developers, as well as to internal, partner, or public groups. |
|||||||||
|
ClientInformation about clients being used to interface with and work with the service, allowing it to be put to use without code, in the browser, on the desktop, or some other installable client that can be used by anyone. |
|||||||||
|
Command Line InterfaceThe command line interface (CLI) tooling being used to developer or consume a service, and integration within larger pipelines, models, and lifecycle implementations. |
|||||||||
|
SDKsWhat software development kits (SDK) are generated, or developed and maintained as part of a service’s operation? Providing the code samples, libraries, and development kits that are needed to put services to use. |
|||||||||
|
PluginsWhat platform plugins are developed and maintained as part of a services operations, allowing it to work with other platforms and services. |
|||||||||
|
IDEAre there integrated development environment (IDE) integrations, libraries, plugins, or availability considerations for each service? |
|||||||||
|
BrowsersAre there any browser plugins, add-ons, bookmarklets and integrations used as part of each service’s operation, providing browser specific client solutions, that are ready to go--no coding necessary. |
|||||||||
|
EmbeddableInformation about any embeddable badges, buttons, widgets, and other JavaScript enabled solutions built on top of a service? |
|||||||||
|
BotsWhat type of automation and bot implementations are in development or being supported as part of a service’s operation? |
|||||||||
|
VisualizationAre there specific visualizations that exist to help present the resources available within any service? |
|||||||||
|
AnalysisHow are logs, APIs, and other aspects of a service being used as part of wider analysis, and analytics strategy? |
|||||||||
|
AggregationAre there any aggregation solutions in place that involve the service, and depend on its availability? |
|||||||||
|
IntegrationWhat 3rd party integrations are available for working with a service in existing integration platforms like IFTTT, and Zapier. |
|||||||||
|
RegionsWhich regions does a service operate within, making it available in specific regions, and jurisdictions–also which regions is it not allowed to operate within. |
|||||||||
|
WebhooksAre there webhooks employed to respond to events that occur via the service, pushing data, and notification externally to consumers? |
|||||||||
|
MigrationWhat solutions are available for migrating an API between regions, cloud environments, and on-premise? |
|||||||||
|
Real TimeAre there Server-Sent Events (SSE), Websocket, Kafka, and other real time aspects of a service’s delivery, allowing for the delivery of content, data, and other resources in real time, using dedicated connections and streams. |
|||||||||
|
TrainingWhat training materials need to be developed, or already exist to support the service. |
|||||||||
|
VoiceAre there any voice or speech enablement, integrating services with Alex, Siri, Google Home, or other conversational interface? Looking at how services can be tailored and evolved to better meet this specific type of client usage, which might be significantly different than other web or mobile client scenarios. |
|||||||||
|
NetworkInformation about networks that are setup, used, and allocated for each service governing how it can be accessed and consumed. |
|||||||||
|
SpreadsheetsWhat types of spreadsheet integrations, connectors, and publishing solutions are available for a service? |
|||||||||
|
InvestmentWhere do the funds for operating a service come from within a company, from external organizations, or VC funds? |
|||||||||
|
MonetizationWhat does it cost to operate a service, breaking down the one time and recurring costs involved with delivering the service. |
|||||||||
|
PlansOutline of plans involved with defining, measuring, reporting, and quantifying value generated around a service’s operation. |
|||||||||
|
PartnersAn overview of partner program involved with a service’s operation, and how a wider partner strategy affects a service’s access and consumption. Establishing a trusted tier of access which high value partners can be organized and given special access to a variety of services, further meeting the platform's goals. |
|||||||||
|
CertificationAre there certification channels available for applications and developers, defining the knowledge required to competently operate and integrate a service. |
|||||||||
|
EvangelismWhat does internal, public, and partner evangelism efforts and requirements look like for a service, and its overall presence? |
|||||||||
|
ShowcaseHow are developers and applications using a service showcased, and presented to the community, demonstrating the valuable around a service? |
|||||||||
|
DeprecationWhat are the plans for deprecating a service, involved the road map and communication around the individual and overall deprecation of service(s). |
|||||||||
|
GovernanceHow are all steps measured, quantified, aggregated, reported upon, and audited as part of a larger quality of service effort for each service. |
|||||||||
|
Finish |