【问题标题】:Strongloop-Loopback query string parametersStrongloop-Loopback 查询字符串参数
【发布时间】:2016-02-16 23:41:55
【问题描述】:

我正在开发一个 REST api,并考虑使用 Loopback 框架来缩短开发时间。

我喜欢这个框架的很多东西(而且它似乎符合我的需要),但我完全不喜欢这个:

http://localhost:3000/api/users?filter[where][username]=john&filter[where][email]=callback@strongloop.com
http://localhost:3000/api/users?filter={"where":{"username":"john","email":"callback@strongloop.com"}}

如果您有一个公开为 REST api 的模型,那么您的网址就是这样。对我来说,这两种选择看起来都很奇怪而且有点难看。当你看到像/cars?filter[where][miles][gt]=5000 这样的例子时,事情似乎更奇怪了。

那么,我可以以某种方式更改所有公开模型的 url 形式吗? (更传统的东西)。我真的很想有正常的查询字符串,如:

http://localhost:3000/api/users?username=john&email=callback@strongloop.com

有没有理由让他们看起来像这样,我应该欣赏这些?有这种语法的 REST api 吗?

谢谢

【问题讨论】:

  • 它有什么不同?我希望您不要手动构建 URL。
  • 我不是使用 api 的人。而且我需要确保我呈现的界面尽可能简单(通常这意味着人们之前已经看过它并且他们知道如何处理它。它很熟悉)。问题不在于使用库来构造查询。为您需要的每个查询参数设置一个像这样的对象 { filter:{where:{username:'me'}}} 会打扰您吗?我会将您的评论视为对“一切都好。我不会有问题”的投票(或者当您提到手动构建网址时,您指的是与 qs 不同的东西吗?)
  • 实际上有一些框架可以发送这样的 URI(两个版本)。我个人首先不会为可用于GET 请求的复杂查询提供资源。这就是我不喜欢第二种选择的原因之一。 JSON 属于请求的正文。另一方面,第一个并不不寻常。 param[] 是一种常见的模式,这个例子肯定比第二个更易读。但查询越复杂,URL 的可读性就越差,即使使用您首选的“正常”解决方案也是如此。
  • 哦。我完全同意 JSON 应该在正文中。我很想把它放在那里,但是 GET with body 还没有(广泛?)支持。或者至少我还没有设法在 jQuery、vanilla js 或我使用的任何其他浏览器插件中发送带有 body 的 GET。我很想做类似弹性搜索的事情,但我不控制客户端。如果我能绕过它,我不喜欢发送帖子而不是获取的想法。

标签: rest url loopbackjs strongloop


【解决方案1】:

Loopback 为您的模型提供 REST 接口,能够对数据执行相当复杂的查询,而无需任何额外的编码。我认为他们已经根据OData 标准对语法进行了建模。所以这就是为什么查询字符串比你想象的要复杂。

在 Loopback 中,您可以使用 Remote Methods 创建自己的自定义端点,这样您就可以创建和公开像 getuser 这样的端点,它接收您指定的参数,从而产生更简单的 API。

【讨论】:

  • 我认为通过查询字符串执行数据库查询只是为了检查我们的逻辑是否有效。然后可以通过将存储逻辑的远程方法创建自定义休息端点。这样您就可以隐藏逻辑并提供简单的休息端点。因为普通的查询字符串无法告诉回环如何处理参数(对于小于或其他复杂的比较)。
猜你喜欢
  • 2017-04-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-04-03
  • 2020-11-09
  • 2017-12-28
相关资源
最近更新 更多