提问人：meaning-matters 提问时间：8/14/2013 最后编辑：meaning-matters 更新时间：10/5/2021 访问量：31633
用于验证信息的 REST 操作（GET、PUT 或 POST）？
Which REST operation (GET, PUT, or POST) for validating information?
问：
我的用户在 iOS 应用中输入一些信息字段。 此信息必须在我的服务器上进行验证，该服务器具有 RESTful API。 验证后，iOS 应用的 UI 将更改以指示结果。
GET、PUT 或 POST 似乎都不合适，因为我没有获取资源，也没有创建或更新资源。
实现此验证的最佳 REST 操作是什么？
答：
15赞
Lukas K
8/14/2013
#1
我使用与您相同的场景，并为此使用 PUT。你必须问自己：“当我两次发送相同的请求时，这会在服务器上产生不同的状态吗？如果是，则使用 POST，如果没有，请使用 PUT。
评论
0赞
8/14/2013
PUT针对哪个 URI？
0赞
Lukas K
9/6/2013
例如，/Login（无论登录多少次，服务器保持不变）
10赞
Kristian
8/14/2013
#2
我的用户在 iOS 应用中输入一些信息字段。此信息 必须在我的服务器上进行验证，该服务器具有 RESTful API。后 验证 iOS 应用程序的 UI 更改以指示结果。我是 未获取资源，也未创建或更新资源。
由于您没有保存任何东西（不修改任何资源），我认为这在技术上比 RESTful 更像 RPC。
以下是我的观点，所以不要把它当作福音：
如果信息只是被提交，而你说是或否，而你没有保存它，我会说没问题。POST
如果信息确实被保存/更新，那么选择正确的HTTP方法将更加重要。
POST = CREATE / SUBMIT (in an RPC context)
PUT = UPDATE (or CREATE if there is nothing to UPDATE)
评论
0赞
meaning-matters
8/14/2013
谢谢你的回答！确实，它闻起来像RPC。甚至 URL 此刻也以结尾。但是，当然，我不想混合一个SOAP RPC或其他东西;-）/check
0赞
meaning-matters
8/14/2013
这个和其他帖子;-）确认你说的话。问题似乎是没有明确的理论答案，而且这是一个实践/解释的事情。
2赞
Kristian
8/14/2013
感谢您跟进该有用的链接。祝你好运。PS，看看 Apigee.com，他们做 API 讨论和操作方法......他们曾经谈到过好的 API 结构，并指出你可以包含装饰现有路由的 RPC 样式方法......即 RESTFUL 普通方法：和用 RPC 装饰的 RESTFUL：它接受您正在验证/检查的参数/resource(/:id)/resource/check
2赞
Plap
6/24/2016
此外，还要注意返回状态代码：当 POST 要创建时，它应该回答 201（已创建），而在您的情况下 （RPC），我认为您可以自由地返回 200（正常）或一如既往的 400（错误请求）。
9赞
user1907906
8/14/2013
#3
我建议使用 a 和 two 请求。此资源的每个实例都表示一组数据的验证。工作流程：ValidationResource
1. 创建新的 ValidationResource
- 请求：
POST /path/to/validations- 要验证为正文的数据
- 响应：
201 CreatedLocation: /path/to/validations/<unique-id-of-this-validation>
2. 查找结果
- 请求：
GET /path/to/validations/<unique-id-of-this-validation> - 职责：
200 OK- 正文：或
{'valid': true}{'valid': false}
- 正文：或
这是一种 RESTful 方法，其中 Validation 是具有服务器状态的 Resource。
5赞
Kamil Roman
8/13/2020
#4
Google 建议使用 REST API 的自定义方法
对于自定义方法，它们应使用以下通用 HTTP 映射：
https://service.name/v1/some/resource/name:customVerb
使用 ： 而不是 / 将自定义动词与 资源名称支持任意路径。例如，取消删除 文件可以映射到 POST /files/a/long/file/name：undelete
来源： https://cloud.google.com/apis/design/custom_methods
因此，为了进行验证，URL 应为 POST /resource：validate
-2赞
Vinay Pratap Singh
6/9/2021
#5
似乎您没有以正确的方式进行验证，如果验证是在服务器端进行的，那么它应该在使用 POST 方法提交数据时发生。然后，您将验证该数据，如果验证失败，则可以引发 400 BAD REQUEST 错误，否则可以创建资源。
这种方法更 RESTful，因为 POST 方法用于创建资源或在验证失败时引发 400
1赞
arjun kumar
10/5/2021
#6
我相信它类似于 GET 实体，但由于我们需要发送数据进行验证，并且在 URL 中发送机密数据是错误的习惯，因为只有有效负载数据由 TLS 加密，因此剩下的唯一方法是 POST 或 PUT。
但是，您可以在 validate 中保存或更新数据（例如。“verified”：false）。根据要求，您可以选择 或（如果没有更新，建议）POSTPUTPOST
POST /user/validate-something
评论
1赞
devops
1/27/2023
stackoverflow.com/questions/323200/......
0赞
ili
9/7/2023
如前所述@alex TLS 参数是不正确的。但是，也许类似的有效论点正在减少服务器/客户端记录敏感信息（如浏览器历史记录等）的机会。
评论