我正在开发一个需要多个步骤/验证来创建资源的 REST API，然后制作一个POST /transfer可能不会创建实际的传输资源（因为它需要额外的步骤），但不会失败，因为它会触发第二步/验证。
在这个答案中，响应是一个不完整或未决的事务，并且该资源包括完成事务的端点，例如/transaction/123/commit或在我的情况下/transaction/123/verification/432，客户端可以继续、中止或完成事务处理。
但是这些端点上可能的响应代码是什么？/transaction/123/commit实际上返回201是因为它创建了事务还是在达到pending状态时创建了事务？
状态码201（已创建）表示创建（至少一个）新的HTTP 资源。创建资源的 URL 在响应的Location标头中发送。
如果POST /transfer创建了资源/transaction/123/commit——也就是说，如果请求/transaction/123/commit现在可能会成功，而之前你有 404（未找到）——那么POST /transfer使用 201 和. 响应是正确的Location: /transaction/123/commit。
如果POST /transfer创建多个资源，则Location必须是“主要”资源（在某种意义上）。
如果POST /transaction/123/commit没有创建任何新资源，则响应 201 是不正确的，即使它确实创建了其他内容（如内部数据库记录）。
如果您无法提供要发送的 URL Location，这可能意味着您没有创建任何新资源，在这种情况下 201 是不正确的。
注意：Location始终与请求 URL 相关，而不是与“API 根”或您可能拥有的任何此类概念相关。例如，如果POST /api/v1/foo/bar创建/api/v1/foo/bar/baz，正确的值Location将包括bar/baz和/api/v1/foo/bar/baz，但不是/foo/bar/baz。
状态码200（OK）表示一般成功。它可用于大多数成功的响应。这是一种安全的后备：它不会说太多，因此保证不会说太多错误并让客户感到困惑。
如果POST /transaction/123/commit在没有创建新资源的情况下成功，则返回 200 是正确的。
除了对GET/的响应之外HEAD，状态码204（无内容）与 200 基本相同。如果您使用 204 表示与 200 不同的内容，那么您可能正在编造一个本地约定——就像编造自己的状态码 275 .
IANA 维护着标准化状态代码的注册表。您可以在此处查找标准化的状态代码，以准确表达您想要表达的意思。
您通常不想使用非标准状态代码，或者不正确地使用标准状态代码，因为这会排除统一接口，而这正是 REST 的重点。
如果您发现自己一直在努力维护统一的接口，那么您可能根本不需要 REST，而应该使用 RPC。