用于验证参数，REST或其他的Web服务API？

Question

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

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

而这里的API（我怀疑这是基于REST）的草图：

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的设计和休息后我发现，什么是错的这个API的设计。

根据Wikipedia，请求和响应建立在资源的表示转移周围。但是我所做的API与资源无关。它不会CRUD任何资源。所有的API都只需要输入，验证它们并返回结果。而且我坚持用这个要求来设计API。

欢迎任何意见/更正此问题。

Answer 1

你说得对，你的问题更适合RPC风格，但它可以很容易地映射到REST。下面是我该怎么做：

在REST中经常使用POST方法来创建新资源。这个新资源的表示被张贴到代表相同类型资源集合的URL。如果操作成功，则返回HTTP状态码“201 Created”，并在休止体（与邮件中发送的消息体基本相同的消息体）中进行表示。返回的Content-Location头显示分配给新资源的URL。如果操作失败，则会在消息体中使用“400错误请求”状态代码和更详细的人类可读错误说明进行信号发送。

正如您所看到的，验证已经是这种常见REST模式的一部分。据我所知，你的情况唯一的区别是你不想在你的服务器上创建（记住）这个资源。所以不要。 REST并没有说你必须。如果您发现它更容易，可以想象该资源确实暂时创建，但之后立即删除。如果参数通过验证并返回消息体中的参数，则返回状态码“200 OK”。否则返回“400错误请求”。

如果动词“验证”在URL中引起了您的困扰（不应该），请将URL命名为其他内容，或许是由三个参数组成的对象的适当名称。

希望这有助于

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