A2A vs REST APIs: delegating a task or operating on a resource

A REST API is for giving client software exact operations on a service’s resources: the client names a resource by its URL and applies a standard HTTP method to it. A2A (Agent2Agent) is for letting one agent hand a goal to another agent, often at another company, and follow the resulting task until it completes, fails, is refused or needs more input.

Both usually run over HTTP, and A2A even defines a REST-style binding. What separates them is who defines the contract. The owner of a REST API designs its resources, fields and rules, and each caller codes against them. A2A fixes one small set of operations for every agent and carries the domain-specific part inside the messages.

Status as of September 26, 2026. REST is an architectural style that Roy Fielding described in his 2000 doctoral dissertation. It has no version and no governing body. The methods and status codes REST APIs rely on are defined in RFC 9110, HTTP Semantics (June 2022). A2A is a Linux Foundation project at protocol version 1.0; its latest release, v1.0.1, shipped on May 28, 2026.

What REST APIs are for

Fielding defined REST as a set of constraints: client-server separation, stateless requests, cacheable responses, a uniform interface, a layered system, and optional code on demand. In practice, “REST API” usually means an HTTP API built around resources:

• Each resource has a URL, such as /orders/A-1001 or /orders/A-1001/refunds.
• The HTTP method carries the intent. RFC 9110 defines GET as safe, meaning essentially read-only, and PUT and DELETE as idempotent: repeating the request has the same intended effect.
• Status codes report the outcome, such as 201 Created, 404 Not Found or 422 Unprocessable Content.
• The server keeps no session between requests. Each request carries its own credentials and context.

Everything else is the API owner’s choice: resource names, field names, error bodies, pagination, versioning and authentication. That precision is the value. A caller that knows the API gets exactly the operation it asked for, and GET responses can be cached by any HTTP cache along the way. The cost is one integration per API, usually written from documentation or an OpenAPI description (see A2A vs OpenAPI).

What A2A is for

A2A defines its operations once for every agent: SendMessage, SendStreamingMessage, GetTask, ListTasks, CancelTask, SubscribeToTask, four push notification configuration methods, and GetExtendedAgentCard. What differs between agents lives in the Agent Card, usually served at /.well-known/agent-card.json: skills described in prose with examples, accepted media types, endpoints in supportedInterfaces, and the security schemes a client must use.

A client sends a message made of text, file and data parts. The agent may answer with a message or create a task. A task can finish (TASK_STATE_COMPLETED), be refused (TASK_STATE_REJECTED), fail, or pause to ask for more input (TASK_STATE_INPUT_REQUIRED) or for authorization (TASK_STATE_AUTH_REQUIRED). The specification treats agents as opaque, so the client never sees the tools, APIs or memory behind the agent.

The same request both ways

Illustrative: a customer’s agent asks a retailer to refund a damaged item.

Against the retailer’s REST API, the caller must already know the resource path, the field names and the allowed reason codes:

POST /v1/orders/A-1001/refunds HTTP/1.1
Host: api.shop.example
Authorization: Bearer illustrative-token
Content-Type: application/json

{"lineItemId": "LI-2", "reason": "DAMAGED_IN_TRANSIT", "amount": {"value": "49.00", "currency": "CAD"}}

The API answers 201 Created with a refund resource, or a 4xx error in a format the API defines. If policy requires a photo first, the caller has to know that in advance, or parse the error and try again.

Over A2A, here with the JSON-RPC binding, the caller states the goal and attaches the data it has:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "8d0f3c1e-5b7a-4e2f-9c61-0a4b2d7e9f13",
      "role": "ROLE_USER",
      "parts": [
        { "text": "Item LI-2 on order A-1001 arrived damaged. Please refund it." },
        { "data": { "orderId": "A-1001", "lineItemId": "LI-2" }, "mediaType": "application/json" }
      ]
    }
  }
}

The retailer’s agent applies its own policy. It might complete the refund and return an artifact with the refund reference, or move the task to TASK_STATE_INPUT_REQUIRED with a message that asks for a photo. The caller replies with a new message that carries the same taskId. When the retailer changes its internal refund API, nothing changes for the caller.

A2A has a REST binding

A2A 1.0 defines three bindings: JSON-RPC 2.0, gRPC and HTTP+JSON. The HTTP+JSON binding is resource-style HTTP. Its URLs come from the HTTP annotations in the normative a2a.proto: POST /message:send, GET /tasks/{id}, POST /tasks/{id}:cancel and GET /tasks/{id}/pushNotificationConfigs, among others. Requests and responses should use application/a2a+json, and errors are google.rpc.Status JSON bodies.

On the wire, then, an A2A agent can look like a REST API. The resources are what differ. Every A2A agent exposes the same generic ones (messages, tasks, push notification configs), and the business meaning travels inside message parts. A REST API exposes the business’s own resources. A2A protocol bindings compares the three bindings in detail.

Side by side

	REST API	A2A
Purpose	Give clients exact operations on a service’s resources	Let one agent delegate a goal to another and track the task
Layer	Architectural style for an HTTP API; each API defines its own resources	Application protocol with a fixed set of operations
Who talks to whom	Any HTTP client and one service	A client agent and a remote agent, often at different organizations
Transport	HTTP	JSON-RPC 2.0 over HTTP, gRPC, or HTTP+JSON; Server-Sent Events for streaming; webhooks for push
Discovery	None defined; documentation or an OpenAPI description	Agent Card at /.well-known/agent-card.json, registries or direct configuration
Auth	Chosen by each API, for example OAuth 2.0 bearer tokens (RFC 6750) or API keys	Declared in the Agent Card: API key, HTTP auth, OAuth 2.0, OpenID Connect or mutual TLS
State	Stateless requests; resource state lives on the server	Tasks with a lifecycle; contextId groups related tasks and messages
Governance and status	Architectural style (Fielding, 2000); HTTP semantics in RFC 9110 (IETF)	Linux Foundation project; version 1.0 (v1.0.1, May 28, 2026)

When to use a REST API

Use REST when the caller should decide exactly what happens and the operation is deterministic: create an order, read a balance, change an address, list invoices. It fits your own applications, known partners, high request volumes and cacheable reads. You get precise control, predictable errors, and the whole HTTP toolchain of gateways, caches and client generators.

When to use A2A

Use A2A when the outcome depends on the other side’s policy or judgment, when the work may take minutes or days, when the other side may need to ask a question first, or when many outside agents need one contract instead of one integration each. Refund decisions, insurance quotes with underwriting questions, and bookings with exceptions all fit. The caller states the goal, and the receiving agent can change its internals without breaking callers.

Using both

Most A2A agents sit in front of REST APIs. The agent receives a task, calls the business’s own APIs to do the work, and returns the outcome as an artifact. The APIs remain the system of record, and the Agent Card becomes the entrance for outside agents.

Three places where the two meet:

• One authorization server. An A2A agent can declare an OAuth 2.0 scheme in its Agent Card and use the same authorization server as your REST APIs.
• Duplicates. RFC 9110 makes PUT and DELETE idempotent, but not POST. The A2A specification says SendMessage may be idempotent and that agents may use messageId to detect duplicate messages. Check messageId before the agent triggers a non-idempotent call behind it.
• Scope checks. A2A requires an authorization check on every operation, and results scoped to what the caller may see even when no filter is given. Those checks run in the agent, in addition to the checks in the APIs it calls.

Common misconceptions

“A2A replaces REST APIs.” A2A agents depend on ordinary APIs to do their work. A2A adds an entrance for other agents and leaves the APIs behind it in place.

“A2A’s HTTP+JSON binding turns my REST API into an A2A agent.” The binding only maps A2A’s own operations onto HTTP. Your API’s resources become reachable over A2A when something, usually an agent, accepts messages and manages tasks in front of them.

“Any JSON-over-HTTP API is REST.” Fielding’s constraints include a uniform interface and stateless, cacheable interactions, and many APIs described as REST follow only some of them. For callers, a documented and stable contract matters more than the label.

“Outside agents can just call our public REST API.” They can, once someone writes the integration and handles your authentication, error formats and policy rules. A2A gives outside agents one contract that works the same way at every company that publishes an Agent Card.