application/cbor

API Design

Meaning

The application/cbor media type identifies HTTP message bodies encoded as CBOR (Concise Binary Object Representation), a binary data format defined in RFC 8949. It solves the problem of clients and servers needing to agree on a compact, schema-less binary encoding when JSON's verbosity or text-based nature is undesirable. This media type is reached for when designing APIs that prioritize payload size, parsing speed, or strict typing over human readability.

Primary Function

Content type identification

Communicative Purpose

Enables content negotiation for compact binary payloads by providing a standardized media type that decoders can recognize and route correctly.

Pattern

Content-Type: application/cbor in HTTP responses; Accept: application/cbor in HTTP requests for content negotiation

Função primária

Content type identification

Propósito comunicativo

Enables content negotiation for compact binary payloads by providing a standardized media type that decoders can recognize and route correctly.

Situações de gatilho

Web clients: requesting compact binary representation via Accept header

Contextos

HTTP/REST APIs, IoT (CoAP), WebAuthn, mobile-to-server communication, binary serialization protocols

Padrão

Content-Type: application/cbor in HTTP responses; Accept: application/cbor in HTTP requests for content negotiation

Colocados típicos

Content-Type header
Accept header
cbor2 (Python)
serde_cbor (Rust)
fxamacker/cbor (Go)
IANA media type registry
CBOR tag registry

Substituições comuns

application/json: human-readable but larger payload
application/octet-stream: generic but loses type information
application/msgpack: similar binary format with different encoding rules

Erros comuns

Not validating Content-Type before parsing: may attempt to decode non-CBOR data and raise errors

Similar / contraste

application/octet-stream: generic binary with no schema or type information

Interferências

Coming from MessagePack: may confuse the two binary formats — CBOR (RFC 8949) and MessagePack have different tag systems and are not interchangeable

Família do chunk

application/json
application/msgpack
application/octet-stream
application/cbor-seq
IANA media type registry

Nuance

Boundary conditions: CBOR has no charset since it is binary; content negotiation via Accept header is required for clients to actually receive CBOR responses

Efeito pragmático

Reduces bandwidth usage and parsing latency compared to JSON for binary-friendly data, enabling efficient machine-to-machine communication over constrained links

Dica de memória

application/cbor: like a shipping label on a binary package — it tells the receiver 'open this with a CBOR decoder, not a JSON parser'.

Nota

Registered with IANA; CBOR sequences (concatenated data items) use the separate application/cbor-seq media type.

Upgrade path

CBOR tag registry (RFC 8949 §7) and deterministic encoding rules (RFC 8949 §4.2) for reproducible signatures

Frequência: LowFormulaicidade: Fully fixedPrioridade de aquisição: Recognition firstPrioridade de output: BothTag de espaçamento: Long-term

Examples

from http.server import BaseHTTPRequestHandler import cbor2 class CBORHandler(BaseHTTPRequestHandler): def do_GET(self): payload = cbor2.dumps({"status": "ok", "items": [1, 2, 3]}) self.send_response(200) self.send_header("Content-Type", "application/cbor") self.send_header("Content-Length", str(len(payload))) self.end_headers() self.wfile.write(payload)

import urllib.request import cbor2 req = urllib.request.Request( "https://api.example.com/data", headers={"Accept": "application/cbor"} ) with urllib.request.urlopen(req) as response: if response.headers.get("Content-Type") == "application/cbor": data = cbor2.loads(response.read()) print(data)

package main import ( "net/http" "github.com/fxamacker/cbor/v2" ) func handler(w http.ResponseWriter, r *http.Request) { payload, _ := cbor.Marshal(map[string]interface{}{ "status": "ok", "items": []int{1, 2, 3}, }) w.Header().Set("Content-Type", "application/cbor") w.Write(payload) }