These are the stops in a modern API lifecycle that I keep track of trying to understand how APIs are being delivered across the space:
|
|
From the simplest definition of what a service does, all the way to the complete OpenAPI definition for each service.
|
|
|
The consistent design of each service leverage existing patterns, as well as the web to deliver each service.
|
|
|
Understanding how hypermedia can be applied at the design level to help us bring more resiliency to our APIs infrastructure.
|
|
|
Trying to learn about about organizations are adopting a microservices way of delivering API driven services to meet their needs.
|
|
|
Plan for handling changes, and the inevitable evolution of each service, its definitions, and supporting code.
|
|
|
The backend database schema, infrastructure, and other relevant information regarding how data is managed.
|
|
|
Looking at pure data and how it is used and made available using APIs as the access point for working with valuable data assets.
|
|
|
Understanding why and how people are scraping data and content instead of using APIs and the imbalance that exists across the web.
|
|
|
Learning how GraphQL and other query languages are being used to make APIs more accessible to targeted consumers who desire access to entire schema.
|
|
|
How is the underlying compute delivered for each service using whether it is in in the cloud or on-premise infrastructure.
|
|
|
Understanding cntainers are being used when it comes to deploying and orchestration API infrastructure.
|
|
|
Keeping an eye on how serverless is changing the conversation and being used to deploy and consume APIs.
|
|
|
What does storage of all heavy objects, media, and other assets involved with the delivery of services.
|
|
|
Understanding where the distributed, encrypted opportunities lie within the blockchain if it exists beyond the hype.
|
|
|
Applying algorithms behind our APIs, going beyond just data, and providing logic and other magic using code.
|
|
|
Details services developed, and deployed, including frameworks and other libraries being used.
|
|
|
Defining what the build, syndication, and orchestration of service deployments and integrations look like, and are executed.
|
|
|
Identifying all backend service, code and infrastructure dependencies present for each service.
|
|
|
Strategy for understanding what search will look like for each individual service, and play a role in larger, more comprehensive search across services.
|
|
|
What proxies are in place to translate, cache, stream, and make services more efficient and secure?
|
|
|
What gateways are in place to defend, protect, route, translate, and act as gatekeeper for service operations?
|
|
|
Keeping an eye on how Google is evolving APIs using HTTP/2 and Protobuf to provide B2B scale APIs.
|
|
|
Details how how services and their underlying data are mocked, virtualized, sandboxed, and made available for non-production usage.
|
|
|
The domain addressing being used for routing, management and auditing of all service traffic.
|
|
|
What is involved with authentication across all services, including key-based approaches, basic authentication, JWT, and OAuth solutions.
|
|
|
Information about how services are composed, limited, measured, reported upon, and managed consistently across all services.
|
|
|
What is being logged as part of service operations, and what is required to participate in overall logging strategy?
|
|
|
The strategy for how all services are required to be published to one or many public, private, and partner developer portals.
|
|
|
Learning how companies are providing getting started pages to help developers get up and running with APIs.
|
|
|
The requirements for what documentation is expected as part of each service presence, defining what the services delivers.
|
|
|
Relevant support channels, points of contact, and best practices for receiving support as an API consumer.
|
|
|
Information about the communication strategy around each service, and how blogs, social, and other channels should be leveraged.
|
|
|
Details on a services road map, and what the future will hold, providing individual service, as well as larger organizational details on what is next.
|
|
|
Expectations, communications, and transparency around what the current bugs, issues, and other active problems exist on a platform.
|
|
|
Translating the road map, and issues into a log of activity that has occurred for each service, providing a history of the service.
|
|
|
What is required when it comes to monitoring the availability and activity of each individual service.
|
|
|
The tactical, as well as strategic testing that is involved with each service, ensuring it is meeting service level agreements.
|
|
|
How is the performance of each service measured and report upon, providing a benchmark for the quality of service.
|
|
|
Tracking on how companies are being more reliable when it comes to their API operations, and ofering a higher level of services with their APIs infrastructure.
|
|
|
What does observability of the service look like, providing transparency and accountability using all of its existing outputs?
|
|
|
What caching exists at the server, CDN, and DNS layers for each service to provide a higher level of performance?
|
|
|
Details regarding what is expected regarding encryption on disk, as well as in transport for each service.
|
|
|
Detailed strategy and processes regarding how each service is secured on a regular basis as part of operations.
|
|
|
Looking at the vulnerabilities, and the effort to patch them that exist across the technology sector and may be impacting APIs.
|
|
|
Tracking on the breaches that are ocurring and trying to learn from them and apply to the world of APIs.
|
|
|
Looking at the more theatrical side of security and what stories are being told to influence and stoke our fears.
|
|
|
Keeping an eye on the unauthorized and rogue APIs that are launched when companies fail to make publicly available APIs accessible to consumers.
|
|
|
Considerations, and legal requirements applied to each service as part of the overall, or individual terms of services.
|
|
|
Details regarding the privacy of platform owners, developers, and end users as it pertains to service usage.
|
|
|
Details regarding what service levels are required to be met when it comes to partner and public engagements.
|
|
|
Information about backend server code, API surface area, data, and client licensing in play.
|
|
|
Studying how copyright is being applied to APIs, and other aspects of deploying technology behind API infrastructure.
|
|
|
Understanding how APIs are being patented by companies, and what impact this will have on the wider API ecosystem.
|
|
|
What branding requirements are in place for the platforms and its partners when it comes to the service.
|
|
|
Information regarding regulations in place that effect service operations, and are required as part of its usage.
|
|
|
Understanding how GDPR is impacting businesses and how APIs can be put to work to help satisfy the regulation.
|
|
|
How are services catalogued and made discoverable, making them accessible to other systems, developers, as well as to internal, partner, or public groups.
|
|
|
Information about clients being used to interface with and work with the service, allowing it to be put to use without code.
|
|
|
The command line interface (CLI) tooling being used to developer or consume a service.
|
|
|
What software development kits (SDK) are generated, or developed and maintained as part of a service’s operation?
|
|
|
What platform plugins are developed and maintained as part of a services operations, allowing it to work with other platforms and services.
|
|
|
Are there integrated development environment (IDE) integrations, libraries, plugins, or availability considerations for each service?
|
|
|
Are there any browser plugins, add-ons, bookmarklets and integrations used as part of each service’s operation?
|
|
|
Information about any embeddable badges, buttons, widgets, and other JavaScript enabled solutions built on top of a service?
|
|
|
Understanding how APIs are being used to connect devices to the Internet, generating more data while also using the cloud for connectivity.
|
|
|
Looking at the industrial side of the Internet of Things, going beyond just consumer level discussions and looking at how business are connecting devices to the Internet.
|
|
|
What type of automation and bot implementations are in development or being supported as part of a service’s operation?
|
|
|
Are there specific visualizations that exist to help present the resources available within any service?
|
|
|
How are logs, APIs, and other aspects of a service being used as part of wider analysis, and analytics strategy?
|
|
|
Looking to learn about how machine learning is being used via APIs, and trying to cut through the hype and understand how it can really be put to work.
|
|
|
Are there any aggregation solutions in place that involve the service, and depend on its availability?
|
|
|
What 3rd party integrations are available for working with a service in existing integration platforms like IFTTT, and Zapier.
|
|
|
Information about networks that are setup, used, and allocated for each service governing how it can be accessed and consumed.
|
|
|
Which regions does a service operate within, making it available in specific regions, and jurisdictions–also which regions is it not allowed to operate within.
|
|
|
Are there webhooks employed to respond to events that occur via the service, pushing data, and notification externally to consumers?
|
|
|
What solutions are available for migrating an API between regions, cloud environments, and on-premise?
|
|
|
What types of backups are in place to bring redundancy to the database, server, storage, and other essential aspects of a service’s operations?
|
|
|
Are there Server-Sent Events (SSE), Websocket, Kafka, and other real time aspects of a service’s delivery?
|
|
|
Are there any voice or speech enablement, integrating services with Alex, Siri, Google Home, or other conversational interface?
|
|
|
What types of spreadsheet integrations, connectors, and publishing solutions are available for a service?
|
|
|
Where do the funds for operating a service come from within a company, from external organizations, or VC funds?
|
|
|
What does it cost to operate a service, breaking down the one time and recurring costs involved with delivering the service.
|
|
|
Outline of plans involved with defining, measuring, reporting, and quantifying value generated around a service’s operation.
|
|
|
An overview of partner program involved with a service’s operation, and how a wider partner strategy affects a service’s access and consumption.
|
|
|
Are there certification channels available for applications and developers, defining the knowledge required to competently operate and integrate a service.
|
|
|
What does internal, public, and partner evangelism efforts and requirements look like for a service, and its overall presence?
|
|
|
How are developers and applications using a service showcased, and presented to the community, demonstrating the valuable around a service?
|
|
|
What are the plans for deprecating a service, involved the road map and communication around the individual and overall deprecation of service(s).
|
|
|
What training materials need to be developed, or already exist to support the service.
|
|
|
How are all steps measured, quantified, aggregated, reported upon, and audited as part of a larger quality of service effort for each service.
|
I’m a big fan of Schema.org. A while back I generated an OpenAPI 2.0 (fka Swagger) definition for each one and published to GitHub. I’m currently cleaning up the project, publishing them as OpenAPI 3.0 files, and relaunching the site around it. As I was doing this work, I found myself thinking more about why Schema.org isn’t the goto schema solution for all API providers. It is a challenge that is multi-layered like an onion, and probably just as stinky, and will no doubt leave you crying.
