1

我打算制作一个 API（作为 Web 服务）来验证用户输入。

API 从用户那里获取 3 个参数作为输入，检查所有参数是否有效，然后将结果（例如：真或假）返回给用户。

这是 API 的粗略草图（我怀疑这是 RESTful）：

URL: http://my.domain.com/validate/v1 (POST)
Required parameter: param1, param2, param3
Result: To response body (XML/JSON) or response header (HTTP status)

但是在谷歌搜索 API 设计和 REST 之后，我发现这个 API 设计有问题。

根据Wikipedia，请求和响应是围绕资源表示的传输构建的。但我正在制作的 API 与资源无关。它不会 CRUD 任何资源。API 所做的只是接受输入、验证它们并返回结果。而且我一直坚持按照这个要求设计 API。

欢迎对此问题提出任何建议/更正。

4

1 回答 1

2

你是对的，你的问题更适合 RPC 风格，但它仍然可以很容易地映射到 REST。这是我的做法：

POST 方法在 REST 中经常用于创建新资源。这个新资源的表示被发布到一个表示相同类型资源集合的 URL。如果操作成功，则返回 HTTP 状态代码“201 Created”以及 repose 正文中的表示（与 post 中发送的消息正文基本相同）。返回的 Content-Location 标头显示分配给新资源的 URL。如果操作失败，则会在消息正文中显示“400 Bad Request”状态代码和更详细的人类可读错误描述。

如您所见，验证已经成为这种常见 REST 模式的一部分。据我了解，您的唯一区别是您不想在服务器上创建（记住）此资源。所以不要。REST 并没有说你必须。如果您发现它更容易，想象一下资源确实是临时创建的，但之后立即被删除。如果参数通过验证，则返回状态码“200 OK”，并在消息体中返回参数。否则返回“400 Bad Request”。

如果动词“验证”在 URL 中打扰您（它不应该），请将 URL 命名为其他名称，也许是由三个参数组成的对象的合适名称。

希望这可以帮助

Ferenc Mihaly http://theamiableapi.com

于 2012-04-25T13:52:56.247 回答