WEB / WEB-07.02

Methods, semantics, and status codes

A method expresses intent; a status communicates the result of that request. Distinguish safe, idempotent, authorized, and completed.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Repeated idempotent PUT

Desired state
Duru intends to replace the existing note label with Pinned; permission is supplied true.
Browser / Duru
PUT: label=Pinned ready; awaiting response
Atlas Application
No request
Resource / local state
Label: Draft
First PUT arrived
Replacement request reached the same target; no commit yet.
Browser / Duru
PUT: label=Pinned ready; awaiting response
Atlas Application
PUT received; policy check
Resource / local state
Label: Draft
First replacement
The allowed action replaces current state with Pinned.
Browser / Duru
Awaiting response
Atlas Application
Fulfilled; 204 ready
Resource / local state
Label: Pinned
204 arrived
Success without content or Content-Length; no JSON parsing.
Browser / Duru
204 received; no content
Atlas Application
Fulfilled; 204 ready
Resource / local state
Label: Pinned
Select the identical request
The example selects the same target and content again; it does not measure loss or retry behavior.
Browser / Duru
Identical PUT ready; awaiting response
Atlas Application
Fulfilled; 204 ready
Resource / local state
Label: Pinned
Repeated PUT arrived
A new request carries the identical intended replacement.
Browser / Duru
Identical PUT ready; awaiting response
Atlas Application
Repeated PUT received
Resource / local state
Label: Pinned
State remains the same
The second fulfilled replacement leaves Pinned; audit count is not the idempotence criterion.
Browser / Duru
Awaiting response
Atlas Application
Repeated fulfillment; 204 ready
Resource / local state
Label: Pinned
Second 204 arrived
This fixture chooses another 204 without claiming a mandatory response-equality rule.
Browser / Duru
204 received; intended state unchanged
Atlas Application
Repeated fulfillment; 204 ready
Resource / local state
Label: Pinned

HEAD metadata, zero content

HEAD intent
Request representation metadata without GET content transfer.
Browser / Duru
HEAD ready; awaiting response
Atlas Application
No request
Resource / local state
Atlas note: GET 10 bytes
HEAD arrived
The server retains the request method for response-body rules.
Browser / Duru
HEAD ready; awaiting response
Atlas Application
HEAD received
Resource / local state
Atlas note: GET 10 bytes
Metadata prepared
200 and Content-Length: 10 describe the would-be GET; actual content is zero.
Browser / Duru
Awaiting response
Atlas Application
200; CL=10; content=0
Resource / local state
Atlas note: GET 10 bytes
HEAD response arrived
The browser uses request context to interpret the absence of a body.
Browser / Duru
200; metadata 10; content 0
Atlas Application
200; CL=10; content=0
Resource / local state
Atlas note: GET 10 bytes
Use the metadata
No representation bytes were received; this response is not a JSON document.
Browser / Duru
Metadata known; body not retrieved
Atlas Application
200; CL=10; content=0
Resource / local state
Atlas note: GET 10 bytes

Concealed 404

GET intent
A public view requests the note; internal existence is withheld from the browser.
Browser / Duru
GET ready; existence unknown; awaiting response
Atlas Application
No request
Resource / local state
Exists=true; disclosure=false
GET arrived
The Application received the target without committing a response decision.
Browser / Duru
GET ready; existence unknown; awaiting response
Atlas Application
GET received
Resource / local state
Exists=true; disclosure=false
Disclosure policy
Fixture policy conceals existence and chooses the same public body as its missing-resource row.
Browser / Duru
Awaiting response
Atlas Application
404 ready: Not found
Resource / local state
Exists=true; disclosure=false
404 arrived
The Fetch outcome fixture resolves with a Response; ok=false.
Browser / Duru
404; ok=false; existence unknown
Atlas Application
404 ready: Not found
Resource / local state
Exists=true; disclosure=false
Respect the evidence boundary
The browser knows the public result without inferring actual absence or permanence.
Browser / Duru
Public result known; existence unknown
Atlas Application
404 ready: Not found
Resource / local state
Exists=true; disclosure=false

ACTORS · STATE · DATA FLOW

A method expresses intent toward a resource

GET requests a current representation; HEAD requests retrieval metadata without transferring its content. POST asks a target to process content according to its own semantics. PUT asks to create or replace known target state using the supplied representation. DELETE asks to remove the association between the target and current functionality; it does not guarantee erasure of every backup byte.

PATCH carries modification instructions rather than a replacement representation; the patch document media format and endpoint contract matter. PATCH is not generally safe or idempotent, although a specific operation can be designed to be idempotent. The method name alone is insufficient for an automatic-retry guarantee.

OPTIONS describes communication options, CONNECT establishes a tunnel, and TRACE performs message loop-back. A standardized HTTP method is not necessarily usable through browser Fetch, which restricts forbidden methods such as CONNECT and TRACE. A non-null body for GET/HEAD also causes the Fetch Request constructor to throw TypeError. General protocol framing and the browser API contract are separate matters.

Atlas /notes/atlas-1 supports GET, HEAD, and PUT, with permissionAllows=true explicitly supplied. Supported methods and a user’s permissions are different sets. A known method unsupported by the target concerns 405 and Allow; an unrecognized or unimplemented method concerns 501.

Safe and idempotent answer different questions

Safe means that the method’s defined intent is read-only. GET, HEAD, OPTIONS, and TRACE are safe. A server may still write access logs; incidental side effects do not alone invalidate that definition. Resource owners must nevertheless avoid executing requested business mutations through safe methods, which automated retrieval and prefetch also use.

Idempotent means repeated identical requests have the same intended server effect as one request. PUT and DELETE are idempotent alongside safe methods; POST has no general such guarantee. The first PUT can return 204 and another repetition can return a different appropriate status; response bytes need not match. Audit entries or revision history can increase per request.

The fixture twice PUTs label=Pinned to the same target. Resource state is Pinned after either completion, with no third state introduced by repetition. The absence of concurrent writers is explicit. Real updates also need conditional requests and concurrency policy. Idempotence does not remove permission checks, and safe does not imply public access to confidential data.

Status classes communicate results, not every underlying fact

1xx supplies interim information; 2xx signals success; 3xx describes redirection or related additional action; 4xx indicates perceived client error; 5xx indicates server error. Read numeric status with method and headers. 201 signals creation; 202 does not promise completed processing. 204 signals fulfillment without additional content.

401 concerns missing valid authentication credentials and requires an applicable WWW-Authenticate challenge. 403 means the request was understood but fulfillment refused, possibly for reasons unrelated to credentials. 404 can mean no current representation was found or existence is deliberately undisclosed; it also does not distinguish temporary from permanent absence. Fixtures with internal exists=true and exists=false return the same 404 body without exposing that difference.

405 concerns target method support, 409 conflict with current resource state, and 415 an unsupported request format. 422 concerns unprocessable instructions in understood, syntactically valid content. Document the application’s mapping; an error response alone proves neither an attack nor a server defect.

Body rules and the browser result

A HEAD response cannot carry content. Content-Length: 10 here describes the 10 bytes that the corresponding GET would have transferred; HEAD’s expected body is zero bytes. If that field is sent for HEAD, it must match the would-be GET content length. A 204 cannot contain content or trailers, and the server cannot send Content-Length; adding Content-Length: 0 is not the correct way to express this rule.

Fetch normally does not reject for an HTTP error status: an arrived 404 resolves the Promise with a Response. Response.ok only means status 200–299; a business job can remain pending after 202. Network errors and aborts follow separate failure paths. Parsing content as JSON is another operation; avoid parsing nonexistent HEAD/204 content.

For an idempotent request, repetition semantics help when a connection fails before the response is received: the first operation may already have applied. Automatically repeating a non-idempotent action merely because no response arrived has no general guarantee. A specific action’s idempotency or status-reconciliation contract requires separate evaluation.

Read every scenario without motion

Safe / rights

A method property is not permission
A safe/idempotent GET still needs resource permission for a confidential note. Artifact permissionAllows=true is supplied; the safe label grants no user entitlement.
Method/status evidence
GET safe / permission separate
Intent/completion gate
No business gate
Business outcome
No outcome
Status was not promoted to completion
Safe intent requests no state mutation. Incidental logging can occur; applying permission only to write methods leaves a protected-read gate missing.
Method/status evidence
GET safe / permission separate
Intent/completion gate
Read entitlement required
Business outcome
No outcome
Retry requires an operation contract
PUT desiredState label=Pinned has the same intended effect across two attempts. General POST/PATCH does not inherit that property; particular operations can be designed more narrowly as idempotent.
Method/status evidence
GET safe / permission separate
Intent/completion gate
Read entitlement required
Business outcome
PUT desired state / POST guarantee absent
404 preserves public equivalence
The privacy404 example returns the same 404 and Not found result when internalExists is true or false. Inferring resource existence from that public status misreads the concealment policy.
Method/status evidence
404 / existence unknown
Intent/completion gate
Read entitlement required
Business outcome
PUT desired state / POST guarantee absent
Content rules are separate from completion
HEAD 200 may carry wouldBeGetOctets=10 but has actualContentOctets=0. PUT 204 has responseContent=null; 204 provides no empty JSON object to parse.
Method/status evidence
404 / existence unknown
Intent/completion gate
HEAD no content / 204 no content
Business outcome
PUT desired state / POST guarantee absent
Failure and intent classes were retained
A network-error rejected Promise leaves server effects unknown. Method/status/operation contracts are explained separately; no malformed requests, external retries or live mutations are generated.
Method/status evidence
404 / existence unknown
Intent/completion gate
HEAD no content / 204 no content
Business outcome
Method semantics / business unknown

202 completion

The 202 HTTP outcome was selected
fetchOutcomes[0] resolves with a 202 Response and ok=true. The status describes acceptance for processing; businessCompleted=false is a separate field in the same row. HTTP success range and job completion answer different questions.
Method/status evidence
202; resolved-response; ok true
Intent/completion gate
Completion not yet reviewed
Business outcome
BusinessCompleted false
Accepted is not promoted to completed
With businessCompleted=false, this example cannot display “job completed.” Response.ok tests only the 200–299 range. Establishing completion needs application state under the operation’s contract.
Method/status evidence
202; resolved-response; ok true
Intent/completion gate
Accepted; no completion
Business outcome
BusinessCompleted false
Action effects depend on their own contract
A separate PUT comparison shows intended effects Draft→Pinned and Pinned→Pinned. That method property establishes neither completion of another action returning 202 nor general POST/PATCH repetition guarantees. These rows are not combined as one operation.
Method/status evidence
Separate comparison: PUT replacement
Intent/completion gate
202 still accepted; no completion
Business outcome
BusinessCompleted false
HTTP404 and network rejection differ
fetchOutcomes[1] resolves with a 404 Response and ok=false. fetchOutcomes[2] rejects with a network error and no known response status; server effects are unknown. These negative comparisons are not new events changing the 202 operation’s application state.
Method/status evidence
404 Response / network rejection separate
Intent/completion gate
202 accepted; separate outcome rows
Business outcome
202 business false; network effect unknown
A retry decision needs more than a generic assumption
An operation lacking a response may already have applied. Evaluate repetition using the method’s intended effect and operation contract; neither 202 nor a rejected Promise means “nothing ran.” This review executes no new request or action.
Method/status evidence
202/404/network rows retained separately
Intent/completion gate
Completion and retry require a contract
Business outcome
202 business false; network effect unknown
The application producer establishes completion
HTTP endpoints and Fetch outcomes provide status/Promise results. The application producer managing job or resource state establishes completion; without evidence matched to the same operation, completion is unknown. The supplied 202 row retains businessCompleted=false.
Method/status evidence
HTTP status and Promise classified separately
Intent/completion gate
Producer: application state; coverage required
Business outcome
202 accepted; business not completed

ASSUMPTION · BOUNDARY · CONTROL

A read-only label is not an access grant

A confidential note can be retrieved with GET. Safe means the client did not request state mutation; it says nothing about sensitivity or ownership. Checking permissions only on write methods leaves protected reads uncovered.

The control is a trusted permission decision for each resource/action and avoidance of requested mutation on safe routes. The supplied permissionAllows=true fixture is not proof of identity verification or an authorization engine. This lesson uses harmless note metadata.

Do not turn retry or status into an incorrect acceptance gate

A normal PUT replacement reaches the same desired state. Assuming every POST shares that guarantee, or that 202 means completion, can duplicate a business action or falsely report an unfinished job as completed. Impact depends on application semantics.

Client controls depend on method, operation contract, and completion evidence. With a generic 404, the client cannot assert resource absence. Defensive review separates internal decision reasons from public results without disclosing hidden existence in the response body.

Read every scenario without motion

PUT state effect

Method context was selected first
The fixture assumes permission for /notes/atlas-1 and no concurrent writer. GET, HEAD and PUT still use different method/content contracts. The assumptions are not actual authorization or concurrency tests.
Operation evidence
Method + resource context
Effect/content review
No effect/byte review
Status-contract review
No verdict
State effects or metadata were checked
The first PUT attempt changes Draft to Pinned; the second retains Pinned. Idempotence is assessed through the intended state effect rather than equality of response strings.
Operation evidence
Method + resource context
Effect/content review
Draft→Pinned / Pinned→Pinned
Status-contract review
No verdict
The absence of 204 content was recorded
Each PUT attempt has 204 and responseContent=null with responseContentLengthField=null. A JSON-body observation is not added to a no-content status.
Operation evidence
204 / content null
Effect/content review
Draft→Pinned / Pinned→Pinned
Status-contract review
No verdict
The second replacement preserves the intended result
Both attempts refer to the same resource and label=Pinned representation, with supplied concurrentWriters=false. The second intended effect still yields Pinned. Audit count or status text does not replace this state comparison.
Operation evidence
204 / content null
Effect/content review
Draft→Pinned / Pinned→Pinned
Status-contract review
No verdict
The state result comes from the application
In an actual review, the application layer changing the resource produces before/after state evidence. Client receipt of 204 signals fulfillment but does not alone measure state history or persistence durability. Match state evidence to the same target and representation.
Operation evidence
204 / content null
Effect/content review
Draft→Pinned / Pinned→Pinned
Status-contract review
Producer: application state; persistence outside scope
Semantic regression retained intended scope
Repeated PUT retains Pinned, and both 204 responses contain no content. These two attempts do not verify concurrent writers or the complete business persistence process.
Operation evidence
204 / content null
Effect/content review
Draft→Pinned / Pinned→Pinned
Status-contract review
PUT effect consistent / concurrent scope omitted

HEAD metadata

HEAD was selected for the same resource
HEAD /notes/atlas-1 requests representation metadata without transferring GET content. The example has wouldBeGetBody=Atlas note and wouldBeGetOctets=10; permission is a supplied predicate, not an actual account decision.
Operation evidence
HEAD /notes/atlas-1; GET 10 bytes
Effect/content review
Metadata and actual bytes separate
Status-contract review
Coverage not yet reviewed
State effects or metadata were checked
HEAD has status 200, contentLengthField=10, actualContentOctets=0. Metadata may describe a would-be GET representation; it does not imply 10 delivered content bytes.
Operation evidence
HEAD /notes/atlas-1; GET 10 bytes
Effect/content review
HEAD metadata10 / actual0
Status-contract review
No verdict
HEAD metadata is not content-byte receipt
contentLengthField=10 describes the would-be GET length; actualContentOctets=0 records that HEAD carries no content. HEAD 200 and PUT 204 are distinct method/status contexts; the 204 null content field is not copied into the HEAD row.
Operation evidence
HEAD /notes/atlas-1; GET 10 bytes
Effect/content review
HEAD 200; CL 10; actual content 0
Status-contract review
HEAD has metadata; no body
Negative fixtures were separated from coverage
The HEAD actualContentOctets>0 predicate flags a supplied inconsistent row. Zero matches from missing rows do not establish measured compliance with the content rule.
Operation evidence
HEAD /notes/atlas-1; GET 10 bytes
Effect/content review
HEAD predicate / coverage separate
Status-contract review
HEAD has metadata; no body
Method context and capture scope are required
The server HTTP producer supplies method/status and would-be GET metadata; the client or a capture with known scope provides actual body-receipt evidence. Losing HEAD context can turn Content-Length into a false delivered-byte count. A zero selector match does not fill missing record coverage.
Operation evidence
HEAD /notes/atlas-1; GET 10 bytes
Effect/content review
HEAD metadata / capture completeness separate
Status-contract review
Producer: server + client/capture; coverage required
Semantic regression retained intended scope
The HEAD metadata/content distinction agrees in the supplied case. Full capture completeness and actual client/server instrumentation need separate evidence.
Operation evidence
HEAD /notes/atlas-1; GET 10 bytes
Effect/content review
HEAD metadata / capture completeness separate
Status-contract review
HEAD metadata consistent / capture unproven

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Correlate method, status, and actual state change

Check intended state effects rather than identical response text when assessing idempotence. The artifact records labels before and after two PUT completions. HEAD observations separate wouldBeGetOctets=10 from actualContentOctets=0. These are instructional records, not an access-log standard.

The XPath selects inconsistent HEAD observations with actualContentOctets>0. Negative and positive fixtures yield 0 and 1 respectively; a missing observation returning 0 cannot verify the body rule. Real traffic requires capture completeness and instrumented server/client context.

Complete the status catalog with the product contract

Compare PUT repetition, HEAD metadata, and 404 public equivalence in the manual exercise. Do not translate 202 into completed, 404 into definitely absent, or 204 into an empty JSON object. Connect results and user-facing messages to the documented application contract.

Read Allow in a 405 as evidence of target method support, not a user’s permission list. A 401 challenge, 403 refusal, and concealed 404 can reflect different operational decisions. Status distributions alone do not diagnose causes; normal client validation and transient service failures can produce the same classes.

NOW APPLY IT TO THE CASE

Which different evidence do method properties and business completion need?

Reading the Atlas note requires permission that the safe GET label does not grant. Repeated PUT retains the Pinned state. A 202 response does not establish completion, and HEAD metadata is not delivered content.

Evaluate the case’s 200, media type and parse-error records separately. Use representation rules to identify the remaining condition for usable data.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Method decision ledger: PUT, HEAD, and concealed 404

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "resource": "/notes/atlas-1",
  "permissionAllows": true,
  "concurrentWriters": false,
  "methods": [
    {
      "method": "GET",
      "safe": true,
      "idempotent": true
    },
    {
      "method": "HEAD",
      "safe": true,
      "idempotent": true
    },
    {
      "method": "POST",
      "safe": false,
      "idempotent": false
    },
    {
      "method": "PUT",
      "safe": false,
      "idempotent": true
    },
    {
      "method": "DELETE",
      "safe": false,
      "idempotent": true
    },
    {
      "method": "PATCH",
      "safe": false,
      "idempotent": false,
      "scope": "General method property; particular PATCH operations can be designed to be idempotent."
    },
    {
      "method": "OPTIONS",
      "safe": true,
      "idempotent": true
    },
    {
      "method": "TRACE",
      "safe": true,
      "idempotent": true
    },
    {
      "method": "CONNECT",
      "safe": false,
      "idempotent": false
    }
  ],
  "put": {
    "desiredState": {
      "label": "Pinned"
    },
    "attempts": [
      {
        "before": "Draft",
        "after": "Pinned",
        "status": 204,
        "responseContent": null,
        "responseContentLengthField": null
      },
      {
        "before": "Pinned",
        "after": "Pinned",
        "status": 204,
        "responseContent": null,
        "responseContentLengthField": null
      }
    ]
  },
  "head": {
    "method": "HEAD",
    "status": 200,
    "contentType": "text/plain; charset=utf-8",
    "contentLengthField": 10,
    "wouldBeGetBody": "Atlas note",
    "wouldBeGetOctets": 10,
    "actualContentOctets": 0
  },
  "privacy404": [
    {
      "internalExists": true,
      "internalDisclosureAllowed": false,
      "status": 404,
      "publicBody": "Not found"
    },
    {
      "internalExists": false,
      "internalDisclosureAllowed": false,
      "status": 404,
      "publicBody": "Not found"
    }
  ],
  "fetchOutcomes": [
    {
      "status": 202,
      "promiseOutcome": "resolved-response",
      "ok": true,
      "businessCompleted": false
    },
    {
      "status": 404,
      "promiseOutcome": "resolved-response",
      "ok": false,
      "existenceConclusion": "unknown"
    },
    {
      "status": null,
      "promiseOutcome": "rejected-network-error",
      "ok": null,
      "serverEffectConclusion": "unknown"
    }
  ],
  "selector": {
    "language": "XPath",
    "xml": "<observations><response method=\"HEAD\" actualContentOctets=\"0\"/></observations>",
    "xpath": "count(/observations/response[@method=\"HEAD\" and number(@actualContentOctets)>0])",
    "expected": 0,
    "positiveFixtureXml": "<observations><response method=\"HEAD\" actualContentOctets=\"1\"/></observations>",
    "positiveExpected": 1,
    "scope": "Only authored protocol-decision observations, not product log field names or a live HTTP capture.",
    "missingFieldBehavior": "Missing observation is insufficient evidence; zero matches is not proof of correct runtime behavior."
  }
}

methods.safe / idempotent: Standard method intent, not a guarantee of permission, encryption, or every API implementation.
put.attempts: Intended state after two replacements with no concurrent writer.
head.contentLengthField: Would-be GET metadata, not the size of transferred HEAD content.
privacy404: Different internal states mapped to the same public status/body.
fetchOutcomes: HTTP outcome, Promise outcome, and business completion kept separate.

Permissions are supplied and replacement is in process. Fetch outcomes are source-grounded fixtures rather than browser/network execution. Equal generic bodies measure neither timing nor complete privacy.

Two reality checks

An idempotent request always returns the same response.

The same intended server effect is required; status and audit/revision side effects may differ. Permission checks still apply.

404 proves absence and makes Fetch reject because it is an error.

404 can conceal existence and normally resolves with a Response. Response.ok is false; network errors are separate.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

The same PUT sets Pinned twice; both return 204. Does idempotence mean identical response bytes?

No; the repeated intended server effect is the same.
Yes; an idempotent method fixes all response headers/body.

Read the explained answer

No; the repeated intended server effect is the same. — The fixture shows Draft→Pinned and Pinned→Pinned; idempotence is not a response-equality guarantee.

HEAD has Content-Length 10 but actualContentOctets 0. Is that contradictory?

Selected lesson artifact fields; teaching example

head: {"method":"HEAD","status":200,"contentType":"text/plain; charset=utf-8","contentLengthField":10,"wouldBeGetBody":"Atlas note","wouldBeGetOctets":10,"actualContentOctets":0}

Yes; HEAD must carry 10 content octets.
No; Content-Length describes the selected GET-body length, while HEAD carries no content.

Read the explained answer

No; Content-Length describes the selected GET-body length, while HEAD carries no content. — WouldBeGetOctets=10 is metadata; actualContentOctets=0 is consistent with HEAD semantics.

What can be inferred about business completion and internal existence from 202 and public 404 outcomes?

Read the explained answer

202 may indicate acceptance while businessCompleted remains false. Public 404 is identical in this fixture for a missing resource and a disclosure-denied resource; existence is unknown. Both statuses come from a received Response; 404 alone is not a fetch rejection.

□ I did not count 202 as completion.

□ I inferred no definite internal absence from 404.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RFC 9110 — HTTP Semantics9.1 Overview · 9.2.1 Safe Methods · 9.2.2 Idempotent Methods · 9.3.2 HEAD · 9.3.3 POST · 9.3.4 PUT · 9.3.5 DELETE · 8.6 Content-Length · 15 Status Codes · 15.3.3 202 Accepted · 15.3.5 204 No Content · 15.5.2 401 Unauthorized · 15.5.4 403 Forbidden · 15.5.5 404 Not Found · 15.5.6 405 Method Not Allowed · 15.5.16 415 Unsupported Media Type · 15.5.21 422 Unprocessable Content
RFC 9112 — HTTP/1.16.3 Message Body Length
WHATWG — Fetch Standard (official source)Methods: safe and CORS-safelisted methods · Request constructor: GET/HEAD non-null body throws TypeError · Response.ok getter: ok status · Fetch methods: processResponse network error rejects promise
MDN — Window: fetch() methodWindow: fetch() method · Return value
RFC 5789 — PATCH Method for HTTP2 The PATCH Method

YOUR NOTES / THIS BROWSER

Methods, semantics, and status codes

1. Core · Mechanism

Repeated idempotent PUT

HEAD metadata, zero content

Concealed 404

A method expresses intent toward a resource

Safe and idempotent answer different questions

Status classes communicate results, not every underlying fact

Body rules and the browser result

2. Red · Trust & Impact

Safe / rights

202 completion

A read-only label is not an access grant

Do not turn retry or status into an incorrect acceptance gate

3. Blue · Secure development & defense

PUT state effect

HEAD metadata

Correlate method, status, and actual state change

Complete the status catalog with the product contract

Which different evidence do method properties and business completion need?

Two reality checks

The same PUT sets Pinned twice; both return 204. Does idempotence mean identical response bytes?

HEAD has Content-Length 10 but actualContentOctets 0. Is that contradictory?

What can be inferred about business completion and internal existence from 202 and public 404 outcomes?

Sources and scope