Skip to main content

Terminology

API

API stands for Application Programming Interface - the contract that lets one program invoke another, defining its operations, inputs, outputs, and errors. In the web context it usually means an HTTP API consumed over the network. It is the unit a kit like this one is built around.

REST

REST stands for Representational State Transfer, the architectural style introduced by Roy Fielding for distributed hypermedia systems. Its constraints (client-server, stateless, cacheable, uniform interface, layered) shape most modern HTTP APIs. "RESTful" usually means resource-oriented over HTTP, even when HATEOAS is omitted.

RPC

RPC stands for Remote Procedure Call, a style where the client invokes a named procedure on a remote server as if it were local. gRPC and JSON-RPC are RPC styles, in contrast to REST's resource orientation. RPC maps naturally to actions and commands rather than nouns.

CRUD

CRUD stands for Create, Read, Update, Delete - the four canonical operations over stored data. In REST they correspond to POST, GET, PUT/PATCH, and DELETE. The term describes the scope of many resource-centric services.

HTTP

HTTP stands for HyperText Transfer Protocol, the application-layer request/response protocol underlying web APIs. Its current semantics are defined by RFC 9110, with HTTP/1.1, HTTP/2, and HTTP/3 differing in transport. Methods, status codes, and headers are HTTP's vocabulary.

HATEOAS

HATEOAS stands for Hypermedia As The Engine Of Application State, the REST constraint that responses carry links to the next valid actions. Clients then navigate by following links rather than hardcoding URLs. It is REST level 3 in the Richardson Maturity Model.

CORS

CORS stands for Cross-Origin Resource Sharing, the browser mechanism letting a server permit cross-origin reads of its responses. It relies on Access-Control-Allow-* headers and, for non-simple requests, a preflight OPTIONS call. CORS is enforced by browsers, not by the server itself.

JWT

JWT stands for JSON Web Token, a compact signed token carrying claims as JSON, defined by RFC 7519. APIs use it as a stateless bearer credential verified by signature. Its payload is encoded, not encrypted, so it must never contain secrets.

OAuth

OAuth (2.0) is an authorization framework, RFC 6749, that grants a third party scoped access to a resource on a user's behalf without sharing credentials. It defines flows such as Authorization Code with PKCE and Client Credentials. Authentication is layered on via OpenID Connect.

OIDC

OIDC stands for OpenID Connect, an identity layer built on top of OAuth 2.0 that adds authentication and an ID token. Where OAuth answers "what may this app do", OIDC answers "who is the user". It standardises user info and discovery endpoints.

TLS

TLS stands for Transport Layer Security, the protocol that encrypts and authenticates HTTP, producing HTTPS. APIs should accept only TLS 1.2+ traffic. It protects credentials and payloads from interception and tampering.

mTLS

mTLS stands for mutual TLS, where both client and server present and verify certificates, not just the server. It is common for service-to-service authentication inside a zero-trust network. It removes the need to ship bearer tokens between trusted services.

ETag

ETag stands for entity tag, an opaque version identifier for a resource representation returned in the ETag header. It drives cache validation via If-None-Match and optimistic concurrency via If-Match. Strong ETags imply byte equality; weak ETags (W/) imply semantic equivalence.

URI

URI stands for Uniform Resource Identifier, the string that names a resource, of which a URL is the locating form. REST addresses resources by URI and acts on them with HTTP methods. Stable, predictable URIs are a hallmark of good API design.

URL

URL stands for Uniform Resource Locator, a URI that both identifies and locates a resource over the network. API endpoints are URLs combining a base, a path, and optional query parameters. HTTP caching is keyed on the URL.

MIME

MIME stands for Multipurpose Internet Mail Extensions, the origin of the media-type system used in Content-Type and Accept. Values like application/json and application/problem+json tell recipients how to parse a body. Vendor types such as application/vnd.api+json support versioning and specs.

SDK

SDK stands for Software Development Kit, here a generated or hand-written client library wrapping an API in idiomatic language calls. SDKs handle auth, retries, pagination, and serialization for consumers. They can be generated from an OpenAPI document to stay in sync.

CRUD vs RPC

This pairing contrasts resource-oriented design (CRUD over HTTP verbs) with action-oriented design (named procedures). REST favours nouns; RPC favours verbs. Many real APIs are hybrids, exposing resources plus a few command-style endpoints.

RFC

RFC stands for Request for Comments, the IETF document series defining internet standards including HTTP (RFC 9110), JWT (RFC 7519), OAuth (RFC 6749), and Problem Details (RFC 9457). Citing the RFC number pins a precise, versioned definition. API design leans heavily on these standards.

CQRS

CQRS stands for Command Query Responsibility Segregation, separating the model used to change data (commands) from the model used to read it (queries). At the API surface it can mean distinct write and read endpoints or even services. It adds complexity justified only when read and write workloads diverge.

BFF

BFF stands for Backend For Frontend, an API layer tailored to the needs of a specific client (web, mobile) that aggregates and reshapes downstream services. It reduces over-fetching and client round trips. Each frontend gets an API shaped for it rather than a one-size-fits-all gateway.

API Gateway

An API gateway is a single entry point that routes requests to backend services and centralises cross-cutting concerns: authentication, rate limiting, TLS termination, and request shaping. It decouples clients from internal topology. Overloading it with business logic, however, turns it into a bottleneck.

SLA

SLA stands for Service Level Agreement, the contractual commitment about an API's availability and performance (e.g. 99.9% uptime). It is backed by measurable SLOs and SLIs. Rate limits and error budgets are often expressed relative to the SLA.

SLO

SLO stands for Service Level Objective, an internal target for a reliability metric such as p99 latency or success rate. It is the engineering goal that supports the externally promised SLA. Breaching an SLO triggers operational response before the SLA is at risk.

p99 Latency

p99 latency is the 99th-percentile response time: 99% of requests complete faster than this value. Tail latency like p99 matters more than the average for user experience and for fan-out calls. API SLOs are commonly stated as p95 and p99 thresholds.

PKCE

PKCE stands for Proof Key for Code Exchange, an OAuth 2.0 extension (RFC 7636) that protects the Authorization Code flow against interception, originally for mobile and SPA clients. The client sends a hashed code challenge and later the verifier. It is now recommended for all Authorization Code flows.

HMAC

HMAC stands for Hash-based Message Authentication Code, a keyed hash used to sign payloads so a recipient can verify integrity and origin. Webhooks commonly include an HMAC signature header computed over the body with a shared secret. The receiver recomputes and compares to authenticate the call.

DTO

DTO stands for Data Transfer Object, a flat object carrying data across a boundary without behaviour. API request and response bodies are DTOs that decouple the public contract from the internal domain model. Keeping them distinct prevents internal changes from leaking to clients.

2xx / 4xx / 5xx

These name the HTTP status-code classes: 2xx for success, 4xx for client errors (the caller must change something), and 5xx for server errors (the server failed). Choosing the right class lets generic clients and proxies react correctly. Returning 200 with an error body breaks this contract.