3.1. 通用语义
3.1. 通用语义 (Generic Semantics)
HTTP 的许多价值在于其 generic semantics, 也就是说, HTTP 定义的 protocol element 可能适用于每个 resource, 而不特定于某个上下文. application-specific semantics 最好通过 message content 和 header field 表达, 而不是通过 status code 或 method 表达 (尽管 status code 和 method 确实具有与 application state 相关的 generic semantics).
generic semantics 与 application-specific semantics 之间的这种划分, 允许 HTTP message 由通用软件处理 (例如 HTTP server, intermediary, client implementation 和 cache), 而不要求这些 implementation 理解正在使用的 application. 它也允许人们利用自己对 HTTP semantics 的知识, 而不需要某个特定 application 的专门知识.
因此, 使用 HTTP 的 application MUST NOT 重新定义, 细化或覆盖 method, status code 或现有 header field 等 generic protocol element 的语义. 相反, 它们应将规范重点放在特定于其 application 的 protocol element 上, 即其 HTTP resource.
更多信息见 [BCP190].
编写规范时, 人们往往想精确规定 HTTP 应如何实现, 支持和使用. 然而, 这很容易导致对 HTTP behavior 形成非预期的 profile. 例如, 常见规范中出现如下表述:
POSTrequest MUST 导致201 Createdresponse.
这会在 client 中形成一种预期, 即 response 总会是 201 Created, 但实际上该 response 完全不确定. 只有当 server 认为已经创建了新 resource 时才预期如此, 但各种原因 (例如 security policy) 可能阻止 server 创建新 resource, 或阻止 server 确认该 resource 已创建.
更合适的表述是:
当 resource 已创建时, 成功的
POSTrequest SHOULD 导致201 Createdresponse.
规范可以使用 protocol element 的具体实例来表示 application-specific semantics. 从某种意义上说, 这就是 generic semantics 针对 application 专门化的方式. 例如, application 可以定义带有特定 Content-Type 的 POST request, 表示 "使用所包含的 representation 创建新 resource". 由于这些语义是 application-specific 的, 它们需要在 application 的规范中定义.
关于 application-defined header field 的具体信息见 Section 4.7.