The Akamai DataStream 2 API: Described by AsyncAPI, Not OpenAPI

The Akamai DataStream 2 API: Described by AsyncAPI, Not OpenAPI

The Akamai DataStream 2 API V2 captures edge log data and delivers it to a destination of your choice at low latency. It is one of 204 APIs that Akamai publishes on the network, and its catalog entry is described by an AsyncAPI event-driven specification — not an OpenAPI one.

That is rare enough in a catalog of this size to be the reason to write about it.

Why the spec type is correct here

DataStream 2 is not a request/response API in the part that matters. You configure a stream — that half is REST, and Akamai’s redesign of the v2 API added stream patching to make configuration incremental rather than replace-the-whole-object. Then the stream runs, and log lines arrive at your destination continuously, at edge volume, forever.

An OpenAPI document can describe the configuration calls. It cannot describe the thing you actually integrate with: a channel, a message shape, a delivery guarantee, a destination binding. That is what AsyncAPI is for, and Akamai using it here is a provider matching the specification to the traffic pattern instead of to habit.

Most providers with a streaming product do the opposite. They publish an OpenAPI file covering the control plane, say nothing machine-readable about the data plane, and leave integrators to reverse-engineer the payload from a documentation page and a sample. The catalog has 1,857 AsyncAPI definitions against 108,265 APIs — the ratio tells you how uncommon it still is to describe the event surface at all.

The control plane / data plane split

This is the shape worth learning from the entry:

  • Control plane — create, patch, activate, and delete streams. Low volume, transactional, REST.
  • Data plane — log records arriving at your S3 bucket, your SIEM, your log aggregator. High volume, one-directional, asynchronous.

Two planes, two traffic patterns, two specification languages. A provider that publishes both is telling an integrator — or an agent — everything it needs to know without a support ticket. A provider that publishes only the first has described the easy half.

What the entry does not carry

The catalog entry’s artifact set is API documentation and the AsyncAPI specification. There is no OpenAPI covering the configuration side, and no base URL recorded on the entry.

So the halves are inverted from the norm: Akamai described the hard part in a machine-readable format and left the easy part to the docs. Given a choice between those two failure modes, this is the better one — the configuration calls are the ones a developer can figure out from a reference page, and the streaming contract is the one they cannot.

Takeaway

An API described by AsyncAPI because AsyncAPI is what fits it. Akamai’s DataStream 2 entry is a small argument that “publish an OpenAPI” is the wrong universal instruction — the right instruction is publish a machine-readable description of the traffic your consumers actually integrate with, in whichever language describes it honestly.

Read the reference at techdocs.akamai.com, and the provider entry at apis.io/providers/akamai/.

← Semiconductors and Hardware on APIs.io
Cybersecurity on APIs.io →