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

The fastest way to make this whole topic area a confusing mess is to just list out technology definitions. This might not be the best way to learn how things work. Though we do need to quickly visit buzzwords like REST, GraphQL, gRPC, webhooks, MCP, and some others. 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 in this article series is look at some use cases and a handful of popular options. And in the very next installment, some live examples and work products of things you can try yourself if you want to dive in a bit. Again, we’re not trying to be coders. We won’t be experts. But sometimes just seeing something actually work can bring those Aha moments we can keep with us over time vs. just spewing buzzwords. It’s the difference between sleepily scanning another bullet point list vs. “oh, yeah… I see how that works now.” (We are going to ask some questions and run some lists first before we get to the fun stuff though.)

A useful direction in this space can perhaps start by asking ”What interaction are you trying to create?” Then look at technologies that can do it. Or you can always ask your dev, architect or AI team members. Yeah, I said it. “AI team members.” While I believe in the “mostly sort of trust, but verify” framework here, at this point, I’ve found our still somewhat new AI friends rise to that level. Maybe they still have that fresh new AI smell, and we still need to sort out best ways to use them, but there you go.

Diving deeper now, we can see 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. All these things matter, but they are not all separate product interaction categories.

A Proposed Useful Starting Taxonomy

This is intentionally simplified and based on need. So it’s not labeled like a normal taxonomy. But we shouldn’t care that much for our purposes here. The goal is to form some mental models based on purpose. Maybe one day I’ll come back and try to build something with proper labels. But I’m more concerned about understanding over form. 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.

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

Which Approach Is Good For What?

These are most likely not going to be choices you will be making alone, (or maybe at all), unless you happen to be in the category “Technical Product Manager”. Most market-focused PMs defining general functionality will not 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 work. So we do still necessarily have to at least gloss over the popular options here.

This won’t be an exhaustive list of interface technologies. Not even close. And these options are not 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 isn’t to list every protocol and platform; just cover enough to build a useful mental model for recognizing major interaction patterns and 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 can work well when consumers genuinely need different combinations of related data. It gives clients more control over response shape, but can also create 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.)

Webhooks work more like this: “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 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 supports a different level of autonomy. Instead of invoking a narrow function, one agent can ask another 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. But don’t yet. Just stick with this series as soon we’re going to get to some hands on views of things.

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.