跳到主要内容

1. 引言

1. 引言 (Introduction)​

Web browsing 以外的应用经常将 HTTP [HTTP] 用作基础, 这种做法有时称为创建 "HTTP-based API", "REST API", 或简称 "HTTP API". 这样做有多种原因, 包括:

  • implementer, specifier, administrator, developer 和 user 都熟悉 HTTP;

  • 存在多种 client, server 和 proxy implementation;

  • 易于使用;

  • Web browser 可用;

  • 可复用 authentication 和 encryption 等现有机制;

  • 目标 deployment 中存在 HTTP server 和 client; 以及

  • 它能够穿越 firewall.

这些 protocol 往往是 ad hoc 的, 只打算部署在一个或少数几个 server 上, 并由有限的一组 client 使用. 因此, 围绕定义 HTTP-based API 形成了一套偏向这些条件的实践和工具.

然而, 当此类应用有多个独立 implementation, 部署在多个未协调的 server 上, 并由多样化的 client 使用时 (标准化工作定义的 HTTP API 通常如此), 面向有限 deployment 的工具和实践可能变得不适用.

这种不匹配很大程度上是因为 API 的 client 和 server 会以不同速度实现和演进, 从而需要具有不同 feature 和 version 的 deployment 共存. 因此, 面向这类 deployment 的 HTTP-based API 设计者需要更仔细地考虑如何处理 service extensibility, 以及如何适应不同 deployment requirement.

更一般地说, 使用 HTTP 的 application protocol 面临许多设计决策, 包括:

  • 是否应定义新的 URI scheme? 是否使用新的 port?

  • 是否应使用标准 HTTP method 和 status code, 还是定义新的 method 和 code?

  • 如何从 HTTP 的使用中获得最大价值?

  • 它如何与 HTTP 的其他用法共存, 尤其是 Web browsing?

  • 如何避免 interoperability problem 和 "protocol dead end"?

Section 2 定义本文档何时适用, Section 3 概述需要保留的 HTTP 重要属性, Section 4 包含使用 HTTP 的 application 规范的 best practice.

本文档主要用于指导 IETF 定义使用 HTTP 并部署在 Internet 上的 application protocol, 但也可能适用于其他情况. 注意, 本文中的 requirement 不一定适用于 generic HTTP extension 的开发.

本文档废弃 [RFC3205], 以反映期间关于 HTTP 的经验和发展.

最后于 更新