Architectural Styles and the Design of Network-based Software Architectures¶
Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures.
Cited by¶
6 citations across 6 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Adjacency Pair
- Network protocols and API design. Request/response with explicit timeout, NACK signalling, and retry policy; the timeout is the operational instantiation of noticeable absence, and repair appears as retry-with-backoff and idempotency keys.
This sourceDefines the REST request/response model with typed response classes (2xx/3xx/4xx/5xx); supports request/response as an engineered adjacency pair with timeout and retry as repair.
- Network protocols and API design. Request/response with explicit timeout, NACK signalling, and retry policy; the timeout is the operational instantiation of noticeable absence, and repair appears as retry-with-backoff and idempotency keys.
- Idempotence
- Without all six parts the property is undefined and the safety argument fails; with them, the spectrum from a projection operator in linear algebra to a Stripe payment-intent retry to a Kubernetes reconciliation loop is analyzed within one diagnostic vocabulary, and the question "is it safe to retry?" becomes a checkable engineering question rather than an ambient hope, as Fielding's (2000) REST architectural style first codified for HTTP methods.
This source(Establishes REST API idempotence contract as design principle; `PUT`, `DELETE` idempotent, `POST` non-idempotent.)
- Without all six parts the property is undefined and the safety argument fails; with them, the spectrum from a projection operator in linear algebra to a Stripe payment-intent retry to a Kubernetes reconciliation loop is analyzed within one diagnostic vocabulary, and the question "is it safe to retry?" becomes a checkable engineering question rather than an ambient hope, as Fielding's (2000) REST architectural style first codified for HTTP methods.
- Interoperability
- Permeability
- A well-designed boundary is selectively permeable — it exposes the intended call (throttled by rate limits, an amount-selective control) while sealing internal state.
This sourceFoundational account of REST and service-boundary design — selective exposure of endpoints and concealment of internal state.
- A well-designed boundary is selectively permeable — it exposes the intended call (throttled by rate limits, an amount-selective control) while sealing internal state.
Domain-specific¶
- HATEOAS
- Request-Response
- REST builds a resource-oriented application layer on top of this exchange primitive.
This sourceThe dissertation defining REST, deriving it by layering resource identification and uniform-interface constraints onto a client-server request-response exchange.
SupportedVerified against the source
- REST builds a resource-oriented application layer on top of this exchange primitive.
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Read against the text for 1 of 6 citations: 1 supported. Each verdict is shown under its citation below, with what in the work backs the sentence.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 1 other way.
Registry ID ref:619f36c25a9e · see in the full table