Web and messaging protocols
These interfaces carry requests and events between applications. Choose a delivery mechanism, then define message meaning, permissions, retries and recovery.
On this page
Overview#
This section covers the general purpose transports and encodings used to connect access control systems, video platforms, intercoms, intrusion systems, cloud services, and automation consumers. It focuses on developer visible contracts and defensive integration behaviour.
Reading map#
| Module | Use it for |
|---|---|
| HTTP and REST | HTTP/1.1, HTTP/2, HTTP/3, resource modeling, retries, caching, authorisation, and safe client behaviour |
| SOAP and XML | SOAP envelopes, WSDL contracts, XML Schema, namespaces, faults, and hardened XML processing |
| WebSocket, SSE, and webhooks | Bidirectional sessions, server to browser streams, and server to server event callbacks |
| MQTT | Brokered telemetry/events, sessions, QoS, retained state, topic design, and ACLs |
| AMQP 1.0 | Brokered or peer messaging with links, credit, settlement, transactions, TLS, and SASL |
| CoAP, OSCORE, and LwM2M | Constrained request/response, object security, observation, and device management profiles |
| CAP and EDXL emergency messaging | Public warning and emergency information envelopes, lifecycle, profiles, and delivery boundaries |
| gRPC and serialisation | Typed RPC, streaming, Protocol Buffers, JSON, and CBOR evolution and parser safety |
Choose by interaction shape#
| Need | Typical fit | Important caveat |
|---|---|---|
| Request/response resource API | HTTP with a documented REST style contract | REST is an architectural style, not a wire standard or automatic security property |
| Contract first XML operations | SOAP/WSDL | Harden every XML parser; schema validity is not authorisation |
| Long lived bidirectional messages | WebSocket | Define an application subprotocol, flow control, liveness, and reauthentication |
| One way browser event stream | SSE | It is server to client only and reconnects automatically |
| Server to server event push | Webhook | Assume retries and duplicates; authenticate the message and constrain callback destinations |
| Many producers/consumers through a broker | MQTT | QoS does not make business side effects exactly once |
| Brokered queues, routing, and link settlement | AMQP 1.0 | Settlement is a messaging outcome, not proof of downstream physical handling |
| Constrained device request/observe | CoAP with an explicit security/profile design | A CoAP ACK is not proof of application or physical outcome |
| Typed internal RPC and streaming | gRPC | Deadlines, compatibility rules, and message size bounds are part of the API contract |
Cross cutting contract#
For every integration, document:
- protocol/version and transport security profile;
- endpoint and trust boundary ownership;
- client/service identity, authentication, and per operation authorisation;
- schema version and compatibility rules;
- timeout, retry, idempotency, ordering, duplicate, and backpressure behaviour;
- maximum request/message/field/depth/stream duration;
- timestamp, clock skew, replay, correlation, and event ID semantics;
- redaction, retention, audit, privacy, and incident behaviour;
- degraded operation and recovery after network partition, credential rotation, or restart.
Example and verification policy#
Examples use synthetic identifiers, documentation domains, and RFC documentation addresses. Don't paste production credentials, tokens, certificates, device identifiers, or callback URLs into them. V1 on this index denotes navigation review; child pages use V2 for standards based technical claims, while deployment evidence remains separately scoped.