用于验证参数、REST 还是其他的 Web 服务 API？答案

【问题标题】：Web service API for validating parameters, REST or else?用于验证参数、REST 还是其他的 Web 服务 API？
【发布时间】：2012-04-26 12:26:03
【问题描述】：

我打算制作一个 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。

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

【问题讨论】：

标签： web-services api rest

【解决方案1】：

您是对的，您的问题更适合 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 命名为其他名称，也许是由三个参数组成的对象的合适名称。

希望对你有帮助

费伦茨·米哈利 http://theamiableapi.com

【讨论】：