Protocol Standardization — APIs and Protocols | OneNoughtOne

0/121

Computer NetworksAPIs and Protocols

APIs and Protocols

LevelIntermediate

Duration60 mins

TopicAPIs and Protocols

2 / 5

Protocol Standardization

The Foundation of Global Interoperability

Imagine a world where every email provider used a different format, every web browser spoke a different language to servers, and every payment system required custom integration work. The internet would be a fragmented mess of isolated islands, each with its own incompatible protocols. This fragmentation is exactly what protocol standardization prevents. Standards are the invisible agreements that allow billions of devices, millions of applications, and countless services to communicate seamlessly. When you browse a website, your browser and the server agree on HTTP. When you send an email, mail servers worldwide agree on SMTP. When APIs exchange data, they agree on JSON or XML formats. Protocol standardization is the discipline of defining, publishing, and evolving these agreements in a way that ensures global interoperability while allowing innovation.

What You Will Learn

By the end of this page, you will understand why standardization is essential, how standards bodies operate, the structure and significance of RFCs, key protocol standards used in APIs, and how to navigate the standards landscape as a software engineer.

Why Standards Matter

Standards provide the common ground that makes the modern internet possible. Without them, every integration would be a custom negotiation between parties. With them, entire ecosystems can emerge. The Core Benefits of Standardization:

Why Standards Are Essential

•Interoperability — Systems from different vendors, written in different languages, running on different platforms can communicate. Your Python service can talk to a Java service through standard HTTP/JSON.
•Reduced Integration Cost — Instead of writing N×M custom integrations (where N and M are the number of systems), everyone implements one standard interface. The world needs N+M implementations, not N×M.
•Innovation Without Permission — Anyone can build compatible software without negotiating with existing players. You can build a web browser without asking Google's permission because HTTP is an open standard.
•Quality Through Collaboration — Standards represent collective expertise. The best minds in industry and academia collaborate to identify edge cases, security risks, and performance optimizations.
•Long-Term Stability — Standardized protocols can remain stable for decades.HTTP/1.1 (RFC 2616) was published in 1999 and remains widely used. This stability protects investments.
•Knowledge Transferability — Engineers who learn standardized technologies apply that knowledge anywhere. HTTP skills transfer between jobs; proprietary protocols don't.

Network Effects of Standards

Standards benefit from powerful network effects. The more implementations exist, the more valuable the standard becomes. This creates a virtuous cycle: adoption drives tooling, which drives further adoption. HTTP's universal adoption means every programming language has an HTTP library, every operating system has HTTP support, and every developer understands HTTP.

The Alternative: A Cautionary Tale Consider the early era of instant messaging (late 1990s-2000s). Each platform—AIM, MSN Messenger, Yahoo Messenger, ICQ—used proprietary protocols. Users had to: Maintain accounts on multiple platforms Run multiple client applications Accept that groups split across platforms couldn't communicate This fragmentation persisted for years because no standard emerged (or was adopted). The industry eventually coalesced around a few dominant platforms, but true interoperability came only with open standards like XMPP and later, protocols for modern messaging. Contrast this with email: Because SMTP was standardized early, you can email anyone with an email address regardless of their provider. Gmail users email Yahoo users who email corporate Exchange users—all seamlessly.

Standards Bodies and Organizations

Protocol standards don't appear spontaneously—they're developed through organized processes by dedicated standards bodies. Understanding these organizations helps you navigate the standards landscape. Major Internet Standards Organizations:

Key Standards Organizations for Network Protocols
Organization	Full Name	Focus Area	Notable Standards
IETF	Internet Engineering Task Force	Core Internet protocols	HTTP, TLS, TCP, IP, DNS, SMTP
W3C	World Wide Web Consortium	Web technologies	HTML, CSS, DOM, WebSocket, XML
IEEE	Institute of Electrical and Electronics Engineers	Hardware/networking	Ethernet (802.3), Wi-Fi (802.11)
ISO	International Organization for Standardization	Cross-industry standards	OSI model, country codes, currencies
OASIS	Organization for the Advancement of Structured Information Standards	Enterprise interoperability	SAML, AMQP, OData
ECMA	Ecma International	Information systems	JavaScript (ECMA-262), JSON (ECMA-404)
OpenAPI Initiative	OpenAPI Initiative (Linux Foundation)	API descriptions	OpenAPI Specification

The IETF Model: Rough Consensus and Running Code The Internet Engineering Task Force (IETF) is arguably the most influential body for application-layer protocols. Its culture is captured in the motto: "We reject kings, presidents, and voting. We believe in rough consensus and running code." — David Clark Key IETF Principles: Open Participation : Anyone can join mailing lists and contribute. There's no membership fee or credential requirement. Working Groups : Standards are developed in focused working groups. The HTTPBIS WG developed HTTP/2 and HTTP/3; the OAUTH WG handles OAuth specifications. Internet Drafts : Work-in-progress documents published for community review. These have no official status and expire after six months. Request for Comments (RFCs) : Finalized standards published in the RFC series. Once published, RFCs are never modified; updates are published as new RFCs. Rough Consensus : Decisions require broad (not unanimous) agreement. Strong objections must be addressed, but perfect consensus isn't required. Running Code : Proposed standards should have working implementations. Unimplementable specifications are rejected.

The W3C Approach

The W3C uses a different process with formal Recommendations, Working Drafts, and Candidate Recommendations. Its focus on web technologies means more emphasis on browser implementations and backward compatibility. W3C specifications often evolve in coordination with WHATWG (Web Hypertext Application Technology Working Group), which maintains 'living standards' like HTML.

Understanding RFCs (Request for Comments)

For network protocols, Request for Comments (RFCs) are the definitive specifications. Every protocol you use daily—HTTP, TCP, DNS, TLS, SMTP—is defined in RFCs. Understanding how to read and reference RFCs is a core skill for network engineers and API developers. RFC Status Levels: Not all RFCs have equal standing. They're classified by maturity:

RFC Maturity Levels

•Proposed Standard — Initial standardization. Suitable for implementation but may change based on experience.
•Draft Standard — Demonstrated interoperability through multiple independent implementations. (Note: This level is no longer used since RFC 6410)
•Internet Standard — Full maturity. Proven through widespread deployment. Examples: TCP (STD 7), IP (STD 5).
•Best Current Practice (BCP) — Operational guidelines rather than protocols. Example: BCP 47 (language tags).
•Informational — Published information, not a standard. Valuable references without normative requirements.
•Experimental — Ideas for experimentation, not intended for production.
•Historic — Obsolete specifications, preserved for reference.

Key RFCs Every API Developer Should Know:

Essential RFCs for API Development
RFC	Title	Significance
RFC 9110	HTTP Semantics	Defines HTTP methods, status codes, headers
RFC 9111	HTTP Caching	How HTTP caching works
RFC 8259	JSON (JavaScript Object Notation)	The ubiquitous data format for APIs
RFC 7519	JSON Web Token (JWT)	Token format for authentication
RFC 6749	OAuth 2.0 Authorization Framework	Standard for delegated authorization
RFC 6570	URI Template	Patterns for URL construction
RFC 7807	Problem Details for HTTP APIs	Standard error response format
RFC 5789	PATCH Method for HTTP	Partial resource updates
RFC 8949	CBOR (Concise Binary Object Representation)	Binary JSON alternative for constrained environments

Reading RFCs: The RFC 2119 Language RFCs use precise language to distinguish between requirements and suggestions. RFC 2119 defines key words that appear in ALL CAPS:

Keyword	Meaning
MUST	Absolute requirement for conformance
MUST NOT	Absolute prohibition
SHOULD	Recommended, but valid reasons to ignore may exist
SHOULD NOT	Discouraged, but not prohibited
MAY	Optional; implementations are free to include or omit

Example from RFC 9110 (HTTP Semantics): A server MUST NOT send more than one Content-Length header field in a response. This sentence mandates behavior. An implementation violating it is non-conformant. A user agent SHOULD send an Accept-Encoding header field... This sentence recommends behavior but allows deviation with justification.

Finding and Reading RFCs

RFCs are freely available at rfc-editor.org and tools.ietf.org. Modern RFC tools provide HTML renderings with cross-references. When implementing a protocol, reading the actual RFC (not just blog summaries) prevents subtle interoperability issues.

HTTP: The Universal API Transport

HTTP (Hypertext Transfer Protocol) has become the de facto standard for API communication. Its ubiquity, tooling ecosystem, and human-readable nature make it the default choice for most web services. Why HTTP Won:

HTTP's Advantages for APIs

•Universality — Every programming language has HTTP libraries. Every firewall understands HTTP. Every browser speaks HTTP.
•Human-Readable — HTTP requests and responses are text. Developers can debug with simple tools like curl or browser DevTools.
•Stateless by Default — Each request is independent. This simplifies scaling (any server can handle any request) and failure handling.
•Rich Semantics — HTTP verbs (GET, POST, PUT, DELETE) map naturally to CRUD operations. Status codes communicate outcomes.
•Extensibility — Custom headers extend the protocol without breaking compatibility. Content negotiation supports multiple formats.
•Cacheability — HTTP's built-in caching semantics (ETag, Cache-Control) enable efficient content delivery.
•Security — TLS (HTTPS) provides encryption, integrity, and authentication. Certificate infrastructure is well-established.

HTTP Method Semantics for APIs: The HTTP specification defines method semantics that RESTful APIs leverage:

HTTP Methods and Their API Semantics
Method	Purpose	Idempotent	Safe	Request Body	Response Body
GET	Retrieve resource	Yes	Yes	No	Yes
POST	Create resource or trigger action	No	No	Yes	Usually
PUT	Replace resource entirely	Yes	No	Yes	Optional
PATCH	Partial resource update	No*	No	Yes	Optional
DELETE	Remove resource	Yes	No	Optional	Optional
HEAD	GET without body (check existence)	Yes	Yes	No	No
OPTIONS	Discover allowed methods	Yes	Yes	No	Yes

Idempotence and Safety

Safe methods don't modify state (read-only). Idempotent methods can be repeated without different outcomes. Idempotence is critical for retry logic: if a request times out, you can safely retry idempotent methods (GET, PUT, DELETE) without worrying about duplicate effects.

HTTP Status Code Standardization: HTTP status codes are grouped by first digit:

Range	Category	Description
1xx	Informational	Request received, processing continues
2xx	Success	Request successfully received, understood, accepted
3xx	Redirection	Further action needed to complete the request
4xx	Client Error	Request has errors; client should fix and retry
5xx	Server Error	Server failed despite valid request; maybe retry

Key Status Codes for APIs: 200 OK : Successful GET, PUT, PATCH 201 Created : Successful POST that created a resource 204 No Content : Successful DELETE with no response body 400 Bad Request : Malformed request (syntax, validation) 401 Unauthorized : Authentication required or failed 403 Forbidden : Authenticated but not authorized 404 Not Found : Resource doesn't exist 409 Conflict : Request conflicts with current state 429 Too Many Requests : Rate limit exceeded 500 Internal Server Error : Unexpected server failure 502 Bad Gateway : Upstream service failure 503 Service Unavailable : Temporary overload or maintenance

Data Format Standards: JSON, XML, and Beyond

APIs need standardized data formats for payloads. The choice of format affects performance, readability, tooling, and interoperability. JSON: The Modern Default JSON (JavaScript Object Notation, RFC 8259) has become the dominant format for web APIs. Its success comes from simplicity:

JSON Example
JSON
1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "user": {
    "id": 42,
    "username": "alice",
    "email": "alice@example.com",
    "roles": ["admin", "developer"],
    "active": true,
    "profile": {
      "display_name": "Alice Johnson",
      "created_at": "2024-01-15T10:30:00Z"
    }
  }
}

JSON Characteristics

•Human-readable: Developers can inspect payloads without special tools
•Language-agnostic: Native support in virtually every language
•Simple type system: Objects, arrays, strings, numbers, booleans, null
•No schema required: Flexible but can be validated with JSON Schema
•Widely tooled: Parsers, validators, formatters everywhere

XML: The Enterprise Legacy XML (Extensible Markup Language) dominated enterprise APIs in the 2000s, particularly with SOAP (Simple Object Access Protocol). It remains relevant in regulated industries and legacy systems.

XML Example
XML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?xml version="1.0" encoding="UTF-8"?>
<user xmlns="http://example.com/api/v1">
  <id>42</id>
  <username>alice</username>
  <email>alice@example.com</email>
  <roles>
    <role>admin</role>
    <role>developer</role>
  </roles>
  <active>true</active>
  <profile>
    <displayName>Alice Johnson</displayName>
    <createdAt>2024-01-15T10:30:00Z</createdAt>
  </profile>
</user>

Binary Formats: Protocol Buffers and Beyond For performance-critical internal APIs, binary formats offer significant advantages:

Data Format Comparison
Format	Human Readable	Size	Schema	Use Case
JSON	Yes	Large	Optional (JSON Schema)	Public APIs, debugging
XML	Yes	Very Large	XSD, DTD	Enterprise, document-centric
Protocol Buffers	No	Small	Required (.proto)	gRPC, internal services
MessagePack	No	Small	Optional	High-performance JSON alternative
CBOR	No	Small	Optional	IoT, constrained devices
Avro	No	Small	Required	Big data, Kafka

Content Negotiation

HTTP's content negotiation allows clients to request preferred formats. The Accept header specifies acceptable response formats (e.g., Accept: application/json). The Content-Type header declares the request body format. This enables APIs to support multiple formats from the same endpoints.

API Description Standards

Beyond transport and data format standards, API description languages standardize how APIs are documented and discovered. These specifications enable tooling for documentation, code generation, testing, and client libraries. OpenAPI Specification (OAS) The OpenAPI Specification (formerly Swagger) is the most widely adopted API description format. It describes REST APIs in a machine-readable format (YAML or JSON).

openapi.yaml
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
openapi: 3.1.0
info:
  title: User Management API
  version: 2.0.0
  description: API for managing user accounts
 
servers:
  - url: https://api.example.com/v2
 
paths:
  /users/{userId}:
    get:
      summary: Get user by ID
      operationId: getUserById
      parameters:
        - name: userId
          in: path
          required: true
          schema:
            type: integer
            format: int64
      responses:
        '200':
          description: Successful response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '404':
          description: User not found
 
components:
  schemas:
    User:
      type: object
      required:
        - id
        - username
        - email
      properties:
        id:
          type: integer
          format: int64
        username:
          type: string
          minLength: 3
          maxLength: 50
        email:
          type: string
          format: email
        roles:
          type: array
          items:
            type: string

OpenAPI Benefits

•Interactive Documentation — Tools like Swagger UI generate live API explorers from specs
•Code Generation — Generate client SDKs in any language from a single source
•Server Stubs — Generate server scaffolding that validates against the spec
•Testing — Auto-generate test cases from path definitions and schemas
•Contract-First Development — Design the API before writing code
•Mocking — Create mock servers for frontend development before backend is ready

Other API Description Standards:

Standard	Purpose	Key Features
GraphQL Schema	GraphQL API definition	Strong typing, introspection, single endpoint
Protocol Buffers (.proto)	gRPC service definition	Binary format, code generation, streaming
API Blueprint	Markdown-based API description	Human-readable, GitHub-friendly
RAML	RESTful API Modeling Language	Reusable patterns, type inheritance
AsyncAPI	Event-driven API description	Websockets, message queues, SSE

Design-First vs Code-First

With API description standards, teams can choose design-first (write the spec, then implement) or code-first (write code, generate spec). Design-first promotes better API design and enables parallel frontend/backend work. Code-first reduces maintenance overhead when APIs change frequently.

Authentication and Authorization Standards

Security is critical for APIs. Standardization in authentication and authorization enables interoperability while maintaining security best practices. OAuth 2.0: The Delegation Standard OAuth 2.0 (RFC 6749) is the industry standard for delegated authorization. It allows users to grant third-party applications limited access to their resources without sharing credentials.

Converting Mermaid diagram...

OAuth 2.0 Grant Types:

Grant Type	Use Case	Security Level
Authorization Code	Web apps with server backend	High (secrets server-side)
Authorization Code + PKCE	Mobile/SPA apps	High (no client secret needed)
Client Credentials	Server-to-server	High (machine identity)
Refresh Token	Token renewal	Medium (requires secure storage)
Device Code	Smart TVs, CLIs	Medium (browser authorization)
Implicit (deprecated)	Legacy SPAs	Low (token in URL)

JWT: The Token Format Standard JSON Web Tokens (RFC 7519) are the standard format for access tokens. JWTs are self-contained: they carry user identity and permissions in a verifiable package.

JWT Structure

Text

Header (algorithm, token type):
{
  "alg": "RS256",
  "typ": "JWT"
}
 
Payload (claims):
{
  "sub": "user:42",            // Subject (user ID)
  "iss": "auth.example.com",   // Issuer
  "aud": "api.example.com",    // Audience
  "exp": 1705312800,           // Expiration (Unix timestamp)
  "iat": 1705309200,           // Issued at
  "scope": "read:users write:orders",  // Permissions
  "email": "alice@example.com"
}
 
Signature:
RSASHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), privateKey)
 
Final Token (three base64url-encoded parts, separated by dots):
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyOjQyIi...

Other Authentication Standards

•OpenID Connect (OIDC): Identity layer on top of OAuth 2.0; adds user info endpoint and ID tokens
•SAML 2.0: Enterprise SSO standard; XML-based, common in corporate environments
•API Keys: Simple but limited; no user context, hard to revoke per-user
•Mutual TLS (mTLS): Certificate-based; both client and server authenticate
•HTTP Basic/Digest: Legacy; avoid for new APIs

Computer NetworksAPIs and Protocols

APIs and Protocols

LevelIntermediate

Duration60 mins

TopicAPIs and Protocols

2 / 5

Protocol Standardization

The Foundation of Global Interoperability

Imagine a world where every email provider used a different format, every web browser spoke a different language to servers, and every payment system required custom integration work. The internet would be a fragmented mess of isolated islands, each with its own incompatible protocols. This fragmentation is exactly what protocol standardization prevents. Standards are the invisible agreements that allow billions of devices, millions of applications, and countless services to communicate seamlessly. When you browse a website, your browser and the server agree on HTTP. When you send an email, mail servers worldwide agree on SMTP. When APIs exchange data, they agree on JSON or XML formats. Protocol standardization is the discipline of defining, publishing, and evolving these agreements in a way that ensures global interoperability while allowing innovation.

What You Will Learn

By the end of this page, you will understand why standardization is essential, how standards bodies operate, the structure and significance of RFCs, key protocol standards used in APIs, and how to navigate the standards landscape as a software engineer.

Why Standards Matter

Standards provide the common ground that makes the modern internet possible. Without them, every integration would be a custom negotiation between parties. With them, entire ecosystems can emerge. The Core Benefits of Standardization:

Why Standards Are Essential

•Interoperability — Systems from different vendors, written in different languages, running on different platforms can communicate. Your Python service can talk to a Java service through standard HTTP/JSON.
•Reduced Integration Cost — Instead of writing N×M custom integrations (where N and M are the number of systems), everyone implements one standard interface. The world needs N+M implementations, not N×M.
•Innovation Without Permission — Anyone can build compatible software without negotiating with existing players. You can build a web browser without asking Google's permission because HTTP is an open standard.
•Quality Through Collaboration — Standards represent collective expertise. The best minds in industry and academia collaborate to identify edge cases, security risks, and performance optimizations.
•Long-Term Stability — Standardized protocols can remain stable for decades.HTTP/1.1 (RFC 2616) was published in 1999 and remains widely used. This stability protects investments.
•Knowledge Transferability — Engineers who learn standardized technologies apply that knowledge anywhere. HTTP skills transfer between jobs; proprietary protocols don't.

Network Effects of Standards

Standards benefit from powerful network effects. The more implementations exist, the more valuable the standard becomes. This creates a virtuous cycle: adoption drives tooling, which drives further adoption. HTTP's universal adoption means every programming language has an HTTP library, every operating system has HTTP support, and every developer understands HTTP.

The Alternative: A Cautionary Tale Consider the early era of instant messaging (late 1990s-2000s). Each platform—AIM, MSN Messenger, Yahoo Messenger, ICQ—used proprietary protocols. Users had to: Maintain accounts on multiple platforms Run multiple client applications Accept that groups split across platforms couldn't communicate This fragmentation persisted for years because no standard emerged (or was adopted). The industry eventually coalesced around a few dominant platforms, but true interoperability came only with open standards like XMPP and later, protocols for modern messaging. Contrast this with email: Because SMTP was standardized early, you can email anyone with an email address regardless of their provider. Gmail users email Yahoo users who email corporate Exchange users—all seamlessly.

Standards Bodies and Organizations

Protocol standards don't appear spontaneously—they're developed through organized processes by dedicated standards bodies. Understanding these organizations helps you navigate the standards landscape. Major Internet Standards Organizations:

Key Standards Organizations for Network Protocols
Organization	Full Name	Focus Area	Notable Standards
IETF	Internet Engineering Task Force	Core Internet protocols	HTTP, TLS, TCP, IP, DNS, SMTP
W3C	World Wide Web Consortium	Web technologies	HTML, CSS, DOM, WebSocket, XML
IEEE	Institute of Electrical and Electronics Engineers	Hardware/networking	Ethernet (802.3), Wi-Fi (802.11)
ISO	International Organization for Standardization	Cross-industry standards	OSI model, country codes, currencies
OASIS	Organization for the Advancement of Structured Information Standards	Enterprise interoperability	SAML, AMQP, OData
ECMA	Ecma International	Information systems	JavaScript (ECMA-262), JSON (ECMA-404)
OpenAPI Initiative	OpenAPI Initiative (Linux Foundation)	API descriptions	OpenAPI Specification

The IETF Model: Rough Consensus and Running Code The Internet Engineering Task Force (IETF) is arguably the most influential body for application-layer protocols. Its culture is captured in the motto: "We reject kings, presidents, and voting. We believe in rough consensus and running code." — David Clark Key IETF Principles: Open Participation : Anyone can join mailing lists and contribute. There's no membership fee or credential requirement. Working Groups : Standards are developed in focused working groups. The HTTPBIS WG developed HTTP/2 and HTTP/3; the OAUTH WG handles OAuth specifications. Internet Drafts : Work-in-progress documents published for community review. These have no official status and expire after six months. Request for Comments (RFCs) : Finalized standards published in the RFC series. Once published, RFCs are never modified; updates are published as new RFCs. Rough Consensus : Decisions require broad (not unanimous) agreement. Strong objections must be addressed, but perfect consensus isn't required. Running Code : Proposed standards should have working implementations. Unimplementable specifications are rejected.

The W3C Approach

The W3C uses a different process with formal Recommendations, Working Drafts, and Candidate Recommendations. Its focus on web technologies means more emphasis on browser implementations and backward compatibility. W3C specifications often evolve in coordination with WHATWG (Web Hypertext Application Technology Working Group), which maintains 'living standards' like HTML.

Understanding RFCs (Request for Comments)

For network protocols, Request for Comments (RFCs) are the definitive specifications. Every protocol you use daily—HTTP, TCP, DNS, TLS, SMTP—is defined in RFCs. Understanding how to read and reference RFCs is a core skill for network engineers and API developers. RFC Status Levels: Not all RFCs have equal standing. They're classified by maturity:

RFC Maturity Levels

•Proposed Standard — Initial standardization. Suitable for implementation but may change based on experience.
•Draft Standard — Demonstrated interoperability through multiple independent implementations. (Note: This level is no longer used since RFC 6410)
•Internet Standard — Full maturity. Proven through widespread deployment. Examples: TCP (STD 7), IP (STD 5).
•Best Current Practice (BCP) — Operational guidelines rather than protocols. Example: BCP 47 (language tags).
•Informational — Published information, not a standard. Valuable references without normative requirements.
•Experimental — Ideas for experimentation, not intended for production.
•Historic — Obsolete specifications, preserved for reference.

Key RFCs Every API Developer Should Know:

Essential RFCs for API Development
RFC	Title	Significance
RFC 9110	HTTP Semantics	Defines HTTP methods, status codes, headers
RFC 9111	HTTP Caching	How HTTP caching works
RFC 8259	JSON (JavaScript Object Notation)	The ubiquitous data format for APIs
RFC 7519	JSON Web Token (JWT)	Token format for authentication
RFC 6749	OAuth 2.0 Authorization Framework	Standard for delegated authorization
RFC 6570	URI Template	Patterns for URL construction
RFC 7807	Problem Details for HTTP APIs	Standard error response format
RFC 5789	PATCH Method for HTTP	Partial resource updates
RFC 8949	CBOR (Concise Binary Object Representation)	Binary JSON alternative for constrained environments

Reading RFCs: The RFC 2119 Language RFCs use precise language to distinguish between requirements and suggestions. RFC 2119 defines key words that appear in ALL CAPS:

Keyword	Meaning
MUST	Absolute requirement for conformance
MUST NOT	Absolute prohibition
SHOULD	Recommended, but valid reasons to ignore may exist
SHOULD NOT	Discouraged, but not prohibited
MAY	Optional; implementations are free to include or omit

Example from RFC 9110 (HTTP Semantics): A server MUST NOT send more than one Content-Length header field in a response. This sentence mandates behavior. An implementation violating it is non-conformant. A user agent SHOULD send an Accept-Encoding header field... This sentence recommends behavior but allows deviation with justification.

Finding and Reading RFCs

RFCs are freely available at rfc-editor.org and tools.ietf.org. Modern RFC tools provide HTML renderings with cross-references. When implementing a protocol, reading the actual RFC (not just blog summaries) prevents subtle interoperability issues.

HTTP: The Universal API Transport

HTTP (Hypertext Transfer Protocol) has become the de facto standard for API communication. Its ubiquity, tooling ecosystem, and human-readable nature make it the default choice for most web services. Why HTTP Won:

HTTP's Advantages for APIs

•Universality — Every programming language has HTTP libraries. Every firewall understands HTTP. Every browser speaks HTTP.
•Human-Readable — HTTP requests and responses are text. Developers can debug with simple tools like curl or browser DevTools.
•Stateless by Default — Each request is independent. This simplifies scaling (any server can handle any request) and failure handling.
•Rich Semantics — HTTP verbs (GET, POST, PUT, DELETE) map naturally to CRUD operations. Status codes communicate outcomes.
•Extensibility — Custom headers extend the protocol without breaking compatibility. Content negotiation supports multiple formats.
•Cacheability — HTTP's built-in caching semantics (ETag, Cache-Control) enable efficient content delivery.
•Security — TLS (HTTPS) provides encryption, integrity, and authentication. Certificate infrastructure is well-established.

HTTP Method Semantics for APIs: The HTTP specification defines method semantics that RESTful APIs leverage:

HTTP Methods and Their API Semantics
Method	Purpose	Idempotent	Safe	Request Body	Response Body
GET	Retrieve resource	Yes	Yes	No	Yes
POST	Create resource or trigger action	No	No	Yes	Usually
PUT	Replace resource entirely	Yes	No	Yes	Optional
PATCH	Partial resource update	No*	No	Yes	Optional
DELETE	Remove resource	Yes	No	Optional	Optional
HEAD	GET without body (check existence)	Yes	Yes	No	No
OPTIONS	Discover allowed methods	Yes	Yes	No	Yes

Idempotence and Safety

Safe methods don't modify state (read-only). Idempotent methods can be repeated without different outcomes. Idempotence is critical for retry logic: if a request times out, you can safely retry idempotent methods (GET, PUT, DELETE) without worrying about duplicate effects.

HTTP Status Code Standardization: HTTP status codes are grouped by first digit:

Range	Category	Description
1xx	Informational	Request received, processing continues
2xx	Success	Request successfully received, understood, accepted
3xx	Redirection	Further action needed to complete the request
4xx	Client Error	Request has errors; client should fix and retry
5xx	Server Error	Server failed despite valid request; maybe retry

Key Status Codes for APIs: 200 OK : Successful GET, PUT, PATCH 201 Created : Successful POST that created a resource 204 No Content : Successful DELETE with no response body 400 Bad Request : Malformed request (syntax, validation) 401 Unauthorized : Authentication required or failed 403 Forbidden : Authenticated but not authorized 404 Not Found : Resource doesn't exist 409 Conflict : Request conflicts with current state 429 Too Many Requests : Rate limit exceeded 500 Internal Server Error : Unexpected server failure 502 Bad Gateway : Upstream service failure 503 Service Unavailable : Temporary overload or maintenance

Data Format Standards: JSON, XML, and Beyond

APIs need standardized data formats for payloads. The choice of format affects performance, readability, tooling, and interoperability. JSON: The Modern Default JSON (JavaScript Object Notation, RFC 8259) has become the dominant format for web APIs. Its success comes from simplicity:

JSON Example
JSON
1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "user": {
    "id": 42,
    "username": "alice",
    "email": "alice@example.com",
    "roles": ["admin", "developer"],
    "active": true,
    "profile": {
      "display_name": "Alice Johnson",
      "created_at": "2024-01-15T10:30:00Z"
    }
  }
}

JSON Characteristics

•Human-readable: Developers can inspect payloads without special tools
•Language-agnostic: Native support in virtually every language
•Simple type system: Objects, arrays, strings, numbers, booleans, null
•No schema required: Flexible but can be validated with JSON Schema
•Widely tooled: Parsers, validators, formatters everywhere

XML: The Enterprise Legacy XML (Extensible Markup Language) dominated enterprise APIs in the 2000s, particularly with SOAP (Simple Object Access Protocol). It remains relevant in regulated industries and legacy systems.

XML Example
XML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?xml version="1.0" encoding="UTF-8"?>
<user xmlns="http://example.com/api/v1">
  <id>42</id>
  <username>alice</username>
  <email>alice@example.com</email>
  <roles>
    <role>admin</role>
    <role>developer</role>
  </roles>
  <active>true</active>
  <profile>
    <displayName>Alice Johnson</displayName>
    <createdAt>2024-01-15T10:30:00Z</createdAt>
  </profile>
</user>

Binary Formats: Protocol Buffers and Beyond For performance-critical internal APIs, binary formats offer significant advantages:

Data Format Comparison
Format	Human Readable	Size	Schema	Use Case
JSON	Yes	Large	Optional (JSON Schema)	Public APIs, debugging
XML	Yes	Very Large	XSD, DTD	Enterprise, document-centric
Protocol Buffers	No	Small	Required (.proto)	gRPC, internal services
MessagePack	No	Small	Optional	High-performance JSON alternative
CBOR	No	Small	Optional	IoT, constrained devices
Avro	No	Small	Required	Big data, Kafka

Content Negotiation

HTTP's content negotiation allows clients to request preferred formats. The Accept header specifies acceptable response formats (e.g., Accept: application/json). The Content-Type header declares the request body format. This enables APIs to support multiple formats from the same endpoints.

API Description Standards

Beyond transport and data format standards, API description languages standardize how APIs are documented and discovered. These specifications enable tooling for documentation, code generation, testing, and client libraries. OpenAPI Specification (OAS) The OpenAPI Specification (formerly Swagger) is the most widely adopted API description format. It describes REST APIs in a machine-readable format (YAML or JSON).

openapi.yaml
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
openapi: 3.1.0
info:
  title: User Management API
  version: 2.0.0
  description: API for managing user accounts
 
servers:
  - url: https://api.example.com/v2
 
paths:
  /users/{userId}:
    get:
      summary: Get user by ID
      operationId: getUserById
      parameters:
        - name: userId
          in: path
          required: true
          schema:
            type: integer
            format: int64
      responses:
        '200':
          description: Successful response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '404':
          description: User not found
 
components:
  schemas:
    User:
      type: object
      required:
        - id
        - username
        - email
      properties:
        id:
          type: integer
          format: int64
        username:
          type: string
          minLength: 3
          maxLength: 50
        email:
          type: string
          format: email
        roles:
          type: array
          items:
            type: string

OpenAPI Benefits

•Interactive Documentation — Tools like Swagger UI generate live API explorers from specs
•Code Generation — Generate client SDKs in any language from a single source
•Server Stubs — Generate server scaffolding that validates against the spec
•Testing — Auto-generate test cases from path definitions and schemas
•Contract-First Development — Design the API before writing code
•Mocking — Create mock servers for frontend development before backend is ready

Other API Description Standards:

Standard	Purpose	Key Features
GraphQL Schema	GraphQL API definition	Strong typing, introspection, single endpoint
Protocol Buffers (.proto)	gRPC service definition	Binary format, code generation, streaming
API Blueprint	Markdown-based API description	Human-readable, GitHub-friendly
RAML	RESTful API Modeling Language	Reusable patterns, type inheritance
AsyncAPI	Event-driven API description	Websockets, message queues, SSE

Design-First vs Code-First

With API description standards, teams can choose design-first (write the spec, then implement) or code-first (write code, generate spec). Design-first promotes better API design and enables parallel frontend/backend work. Code-first reduces maintenance overhead when APIs change frequently.

Authentication and Authorization Standards

Security is critical for APIs. Standardization in authentication and authorization enables interoperability while maintaining security best practices. OAuth 2.0: The Delegation Standard OAuth 2.0 (RFC 6749) is the industry standard for delegated authorization. It allows users to grant third-party applications limited access to their resources without sharing credentials.

Converting Mermaid diagram...

OAuth 2.0 Grant Types:

Grant Type	Use Case	Security Level
Authorization Code	Web apps with server backend	High (secrets server-side)
Authorization Code + PKCE	Mobile/SPA apps	High (no client secret needed)
Client Credentials	Server-to-server	High (machine identity)
Refresh Token	Token renewal	Medium (requires secure storage)
Device Code	Smart TVs, CLIs	Medium (browser authorization)
Implicit (deprecated)	Legacy SPAs	Low (token in URL)

JWT: The Token Format Standard JSON Web Tokens (RFC 7519) are the standard format for access tokens. JWTs are self-contained: they carry user identity and permissions in a verifiable package.

JWT Structure

Text

Header (algorithm, token type):
{
  "alg": "RS256",
  "typ": "JWT"
}
 
Payload (claims):
{
  "sub": "user:42",            // Subject (user ID)
  "iss": "auth.example.com",   // Issuer
  "aud": "api.example.com",    // Audience
  "exp": 1705312800,           // Expiration (Unix timestamp)
  "iat": 1705309200,           // Issued at
  "scope": "read:users write:orders",  // Permissions
  "email": "alice@example.com"
}
 
Signature:
RSASHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), privateKey)
 
Final Token (three base64url-encoded parts, separated by dots):
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyOjQyIi...

Other Authentication Standards

•OpenID Connect (OIDC): Identity layer on top of OAuth 2.0; adds user info endpoint and ID tokens
•SAML 2.0: Enterprise SSO standard; XML-based, common in corporate environments
•API Keys: Simple but limited; no user context, hard to revoke per-user
•Mutual TLS (mTLS): Certificate-based; both client and server authenticate
•HTTP Basic/Digest: Legacy; avoid for new APIs

Protocol Standardization

The Foundation of Global Interoperability

Why Standards Matter

Standards Bodies and Organizations

Understanding RFCs (Request for Comments)

HTTP: The Universal API Transport

Data Format Standards: JSON, XML, and Beyond

JSON Characteristics

API Description Standards

Authentication and Authorization Standards

Other Authentication Standards

There’s more to understand.

Protocol Standardization

The Foundation of Global Interoperability

Why Standards Matter

Standards Bodies and Organizations

Understanding RFCs (Request for Comments)

HTTP: The Universal API Transport

Data Format Standards: JSON, XML, and Beyond

JSON Characteristics

API Description Standards

Authentication and Authorization Standards

Other Authentication Standards

There’s more to understand.