RESTful 应用程序，想要将 SQL 查询作为读取请求发送
我正在开发一个 RESTful Web 应用程序。现在我想扩展读取 (GET) 请求来处理类似 SQL 的查询，但由于所有特殊字符（“”、“/”、“<”、“>”），我无法将它们编码到 URL 中。 “， “{“， “}“， ETC。）。我已经读到，在 GET 请求中使用消息正文并不是一个好主意。所以目前我看到的唯一选择是使用 POST 请求。但我想说这也不是一个好的解决方案，因为我会使用 POST 进行读取操作。根据 REST 原则，读取应该通过 GET 请求来完成，而 POST 只能用于操作数据。
你怎么认为？将类似 SQL 的查询发送到我的 Web 应用程序的最佳方式是什么？
多谢
I'm working on a RESTful web application. Now I want to extend the read (GET) request to handle SQL-like queries but I was not able to encode them into the URL because of all the special characters (" ", "/", "<", ">", "{", "}", etc.). I already read that it is no good idea to use the message body in a GET request. So at the moment the only option I see is to use the POST request. But than again I would say that this is not a good solution either because I would use POST for a read operation. According to the REST principles read should be done by the GET request and POST should only be used to manipulate data.
What do you think? What's the best way to send an SQL-like queries to my web application?
Thanks a lot
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用
CGI::escape("从 NEVER_DO_SUCH_THINGS 中选择 *，其中 SQL_INJECTION > '不安全'")
Use
CGI::escape("select * from NEVER_DO_SUCH_THINGS where SQL_INJECTION > 'unsafe'")
有关如何将查询操作填充到 URI 中的示例，请参阅 OData URI 约定 。
但是，您过度限制了 POST 的使用。 HTTP 方法的想法是，当请求的特征符合 GET、PUT 和 DELETE 的特征时，您应该使用它们。如果特征不匹配，您不得使用它们。然而，POST 是一种通配符方法，可用于任何请求。
不要求 POST 必须以任何方式写入、更新或操作数据。通过告诉客户端它需要使用 POST 方法，您只是没有向客户端做出有关服务器行为的任何承诺。
使用 POST 提交用于查询的数据块没有任何问题。缺点是 POST 的响应不会被缓存，因此您无法利用它。
有许多混合方法，其中之一是 POST 查询参数，让服务器创建一个表示查询的新临时资源，然后返回重定向，以便客户端获取临时查询资源。
See the OData URI Conventions for one example of how to stuff query operations into a URI.
However, you are over-constraining the use of POST. The idea of the HTTP methods is that when a the characteristics of a request fit those of GET, PUT and DELETE you SHOULD use them. You MUST NOT use them if the characteristics do not match. However, POST is a wildcard method that can be used for any request.
There is no requirement that POST must write, update or manipulate data in any way. By telling a client that it needs to use the POST method you are just not making any promises to the client about the behaviour of the server.
There is nothing wrong with using POST to submit chunks of data to be used for queries. The downside is that the response of a POST is not cached and therefore you cannot take advantage of that.
There are numerous hybrid approaches, one of which is to POST the query parameters and have the server create a new temporary resource that represents the query and then return a redirect so the client does a get on the temporary query resource.