Negotiation selects among representations the server can actually produce. Request preferences are inputs to that decision, not evidence that the response will satisfy them. A client still needs to inspect the selected representation. Vary records the request dimensions relevant to reuse; it does not identify the chosen format, language, or compression method. ...
Backward compatibility comes from never reusing a field number and from defaulting to new, unknown fields being skipped rather than fatal. Numbers pin the contract A protobuf field is committed to a wire identity the moment it is given a number, and that number is the contract, not the name. Renaming a field is safe, changing its wire number is a breaking change. So the mapping of tag numbers to meanings must be adjudicated carefully and never reused for a different type, because old binaries holding the old meaning will decode it wrongly the moment the number is reassigned. ...
An idempotency key names an intended action, not a transmission attempt. When a service supports it, the client sends the same key when retrying that action after an uncertain result. Generating a new key for every retry tells the server something different: this is another action, which may legitimately produce another business effect. ...
One resource can have an HTML view for people and a JSON representation for programs. Sharing a URL is useful only when the origin and its intermediaries preserve that distinction. The endpoint must select an available format, serialize it honestly, describe its cache variation, and validate the selected representation rather than some other version of the same resource. ...
A URL identifies a target resource; the request method describes the operation the client asks the origin to apply. Together they form a contract read by the server, caches, proxies, crawlers, and retrying clients. A method is not a decoration on a path. It is a promise about the intended effect, and infrastructure can only make safe decisions when that promise is honest. ...
An idempotency key identifies one logical action only within a service’s defined scope and retention window. Reusing the same text is not a universal exactly-once guarantee. The service must associate that identity with the right principal and operation, coordinate competing attempts, and retain enough authoritative information to recognize the action later. ...
An HTTP method describes the action requested on a target resource. Clients and intermediaries use those semantics when deciding whether to fetch, cache, or retry. Choosing a familiar verb is only the beginning: the application must implement the behavior that the verb promises. Calling a destructive operation GET does not make it safe. A useful API documents its resource model, representation, authorization, and error conditions alongside the method. ...
HTTP idempotency concerns the intended effect of repeating an identical request, not whether every response looks the same. This distinction matters when a connection closes after the server applies a change but before the client receives the answer. Repetition can be appropriate, but only within the operation’s actual semantics and the client’s retry policy. ...