In this part 2 of 5 for the series, we’re going to look at the “What & When”

The fastest way to make this whole topic area a confusing mess is to just list out technology definitions, though at some point we need to visit REST, GraphQL, gRPC, webhooks, Kafka, WebSockets, MCP and A2A. They don’t all sit at the same conceptual level, and they’re not interchangeable answers to one problem. What we’re going to do is look at some use cases. And later on some actual examples and things you can try yourself if you want to dive in a bit. Again, not trying to be coders. We won’t be experts. But sometimes just seeing something actually work can be those Aha moments we can keep with us over time vs. just spewing buzzwords. We’ll get there.

In the meantime, a useful product taxonomy can perhaps start by asking ”What interaction are you trying to create?” Then look at technologies that can do it. Or ask your dev or architect counterparts.

Things like OpenAPI and AsyncAPI can describe interfaces. OAuth 2.0 handles delegated authorization. JSON and Protocol Buffers represent data. SDKs package interfaces for developers. HTTP, WebSockets and MQTT move information. Those things matter, but they are not all separate product interaction categories.

A Proposed Useful Starting Taxonomy

Need	Pattern	Typical choices	Choose it when…
Known resource or action	Request / response	REST	The consumer knows what it wants and expects a direct result
Client-shaped related data	Query	GraphQL	Different clients need different data shapes
Strongly defined remote operation	RPC	gRPC	Services need efficient, typed method calls
Notification that something happened	Event notification	Webhooks	The provider should notify rather than be polled
Decoupled asynchronous processing	Messaging / eventing	Kafka, AMQP, MQTT	Producers and consumers should not depend on immediate responses
Ongoing live updates	Stream / subscription	SSE, WebSockets	Information changes continuously
AI discovers and invokes capabilities	Agent to tool	MCP	An AI application needs structured tools or context
Another agent owns a task	Agent to agent	A2A	Independent agents need to delegate and coordinate outcomes

This is intentionally simplified. gRPC can stream. GraphQL can support subscriptions. Webhooks are HTTP requests initiated by the provider. The goal is not a perfect computer-science classification. It is a durable first question for product work.

Which Approach Is Good For What?

These are most likely not going to be choices you will be making alone, unless you happen to be the category of “Technical Product Manager” and have actual depth of skills here. Most market-focused PMs defining general functionality will not have to go this deep. However, depending on level and responsibilities, product may still need to make balanced choices here in association with technical counterparts. And in any case, should know how things generally work. So we do still necessarily have to at least gloss over the popular options for the stacks here.

This won’t be an exhaustive list of interface technologies, not even close. And these options are not really direct competitors. They’ve been chosen as examples because they’re among the most prevalent, influential, or strategically relevant approaches a product manager is likely to encounter today. The point here isn’t to list every protocol and platform; just cover enough to build a useful mental model for recognizing major interaction patterns and perhaps what questions to ask.

Some of the following are architectures, frameworks or protocols, and so on. They’re not necessarily just some software package where you run an install and go. It’s likely that some have their favorite that didn’t happen to make this list. I’m just trying to offer a representative sample of what seems to be most common in use.

REST (Representational State Transfer) is still a strong default for public APIs and straightforward integrations. Choose it when resources and operations are predictable and familiarity matters. It’s important to note that REST is more an architectural style for designing networked systems, most commonly HTTP APIs. It’s not like you just install REST. (Intro · Video — YouTube)

GraphQL earns its complexity when consumers genuinely need different combinations of related data. It gives clients more control over response shape, but also creates schema, authorization and performance-governance work. (Intro · Video — YouTube: From Zero to GraphQL in 30 Minutes)

gRPC fits naturally in service-to-service environments where typed contracts, generated clients and efficiency matter more than public-API familiarity. (Intro · Video — YouTube: gRPC in 5 Minutes) (Note: gRPC was originally created by Google and is now an open-source CNCF project. Despite the name and its Google origins, the “g” does not officially stand for Google; gRPC recursively expands to “gRPC Remote Procedure Calls.”)

Webhooks fit the sentence, “Tell me when this happens.” They often replace repeated polling for payments, deliveries, job completion and similar events. (Intro · Video – YouTube: Webhooks in 5 minutes.)

Asynchronous messaging fits systems where producers should publish work or events without waiting for consumers, especially when several consumers may react independently or event volume is high. AsyncAPI provides a standard way to describe these message-driven contracts. Apache Kafka is a major event-streaming platform in this category. MQTT is especially important in connected-device environments because it uses a lightweight publish/subscribe model designed for constrained devices and limited or unreliable networks. In other words, IoT matters here, but “IoT” itself is not one separate interface pattern. Devices may use messaging, request/response, streaming, command/control, or several of these. (Intro — AsyncAPI · Apache Kafka · MQTT)

SSE and WebSockets fit live application experiences. SSE is useful for a one-way stream from server to browser. WebSockets fit ongoing bidirectional communication. (Intro — SSE · Intro — WebSockets)

MCP fits AI applications that need discoverable, structured access to tools and context. The current protocol exposes concepts such as tools, resources and prompts, while continuing to evolve underneath that basic product relationship. (Intro)

A2A fits a different level of autonomy. Instead of invoking a narrow function, one agent can ask another independent agent to manage a task and return progress or results. A2A v1.0 explicitly describes itself as complementary to MCP rather than a replacement. (Intro · Video — YouTube: official A2A intro)

Useful primary references include the OpenAPI Specification, GraphQL Specification, gRPC concepts, AsyncAPI, MCP and A2A.

What Did We Leave Out?

Just to fill up the acronym soup bowl, if you really want you can seek out some of these: SOAP, XML-RPC, JSON-RPC, AMQP, NATS, ZeroMQ, WebRTC, GraphQL subscriptions, Apache Pulsar, RabbitMQ, AWS SNS/SQS, Google Pub/Sub, Azure Service Bus, EDI, OData, OPC UA, CoAP and many industry-specific protocols.

Connected devices and industrial systems are worth calling out because their constraints can be quite different from a browser or cloud service. MQTT is one example for lightweight device messaging. OPC UA spans industrial sensors, actuators, control systems, enterprise software and cloud integration. Depending on the product, you may also run into Bluetooth LE, Modbus, CAN, CoAP and other device- or industry-specific approaches. Again, that does not mean “IoT” needs its own box in the taxonomy. It means the consumer and operating environment may change which patterns and technologies make sense.

And not every important integration is an always-on API, event stream or message broker. Enterprise products still exchange enormous amounts of business information through scheduled files, SFTP or object-storage drops, EDI and other batch-oriented mechanisms. X12 remains widely used for business-to-business transactions in areas such as healthcare, finance, transportation and supply chain, while UN/EDIFACT remains a global EDI standard. Old does not necessarily mean obsolete.

From the industry-specific perspective, if you’re in a vertical market, you very likely need some familiarity with the standards in those spaces. Healthcare, finance, retail, manufacturing and more have a variety of specifications, some of which may even be ISO standards.

If you wait a few months, we’ll probably have even more!

The More the Merrier?

As mentioned, you could easily use multiple technologies within a product and with any complexity of features / functions, chances are that will be the case. A logistics platform may use REST for partner integrations, GraphQL for an operations dashboard, gRPC between internal route services, webhooks for delivery events, asynchronous messaging so package scans can fan out to multiple downstream systems, a stream for live vehicle positions, MQTT for some vehicle or device telemetry, MCP tools for an AI service assistant, and A2A for delegating a complex exception to a specialist agent.

It’s clear in this case that each piece can solve a different interaction problem.

The PM’s job is not to pick a favorite acronym. It is to understand the relationship the product needs to create, and the trade-offs it introduces. Maybe. It will depend on the technical depth required in a particular PM role. But most any PM role, at any level, will benefit from understanding how major components of the product are wired together and interact with others.