我正在设计一个REST服务，并且需要检查地址是否被正确输入。我在想的是如何设计一个REST接口来检查完整的街道地址是否有效。在REST服务中返回true/false？
我有这个/地址服务，我可以例如做一个POST /address/validation它返回一个xml/json true或false，但它似乎对我来说是非常不安全的。
另一种方法是做一个GET /address?street=xxx&nr=xxx&zipcode=xxx（和几个更多的参数），并返回200 OK如果正确或404如果不正确，则返回200 OK，这可能更加REST-ful？
我开始做选项1），但更多的我想这件事，选择2）用GET感觉更好...
想法？
从RESTful的角度来看，您真的会返回一个新资源，将其称为AddressValidation，它将包含您的真实值或错误值。所以一种方法是做一个POST到/addressvalidation?street=xxx等。我会很好地返回结果作为JSON或使用状态代码。虽然我不确定404是否合适。你可能想看看this discussion of validation return status codes。
我和你提出的GET /address?street=xxx&nr=xxx&zipcode=xxx方法有同样的问题。对我来说，如果它返回404，这意味着地址是字面上没有找到（即不存在于数据库中），而不是它是无效的（例如，邮政编码是无效的格式;不能有任何这样的地址）。再次看到链接的讨论;似乎400是一个更合适的回应。
我觉得做POST和返回状态代码（如果正确的话200 OK或者如果不正确的话404找不到）比较安静。因为你没有获得某些东西，所以GET看起来不合适。您正在向服务器发送一些信息，并执行一些处理（验证）并返回一些响应。
如果你问我，POST看起来不太好。 RFC规定“POST方法用于请求源服务器接受请求中包含的实体作为Request-Line中Request-URI标识的资源的新下属” – bluehallu 2014-03-18 10:08:50
在这种情况下获取比POST更好，因为手术是幂等的 – 2017-06-19 20:23:13
怎么样？
GET /addressValidity?street=xxx&nr=xxx&zipcode=xxx
=>
200 OK
Content-Type: text/plain
true
感谢Darrel，这很简单，我喜欢它。它超出了我们通常返回的xml或json依赖于accept-headers的正常行为。 – 2011-04-29 08:34:47
@Johan很明显，你可以使用任何你喜欢的媒体类型。 Text/plain对于返回简单标量值非常好。令人遗憾的是，目前对“xml或json”的痴迷实际上失去了REST带来的一些好处，并且能够使用多种不同的媒体类型。 – 2011-04-29 11:18:46
你可以返回一个对象，比如'{“result”：true}' – 2017-06-19 20:23:57
谢谢雅各布。实际上，我们将在这里测试两件事 - 如果地址格式正确，则在这之后我们检查地址是否确实存在。正如你所说，这些是两件不同的事情，应该返回不同的代码/数据。 – 2011-04-29 08:36:54