5

I'm working on a REST api, and thinking about cutting down on development time by using the Loopback framework.

I like a lot of things about the framework (and it seems to fit my needs), but I completely dislike this:

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"}}

If you have a model that you expose as a REST api, that's how your urls look like. For me both options look strange and kind of ugly. And things seem even weirder when you get to examples like this /cars?filter[where][miles][gt]=5000.

So, can I somehow change the form of the url for all exposed models? (to something more traditional). I would really like to have normal query strings like:

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

Is there a reason they look like that and that I should appreciate over looks? Any REST apis with this syntax around?

Thanks

Ana F
  • 641
  • 4
  • 13
  • What difference does it make? You don't construct the URLs manually, I hope. – a better oliver Nov 16 '15 at 16:58
  • 1
    I'm not the one using the api. And I need to make sure the interface I present is as simple as possible (usually that means people have seen that before and they know what to do with it. It's familiar). The problem isn't using a library to construct the query. Does it bother you to have an object like this { filter:{where:{username:'me'}}} for every query param that you need? I'll take your comment as a vote towards "All's good. I wouldn't have problems with that" (or were you referring to something different than qs when you mentioned manually building the url?) – Ana F Nov 16 '15 at 18:51
  • There are actually frameworks that send URIs like that (both versions). I personally wouldn't provide a resource for complex queries that are available for `GET` requests in the first place. That's one reason why I dislike the second alternative. `JSON` belongs into a request's body. The first one on the other hand isn't _that_ unusual. `param[]` is a common pattern and the example is definitely more readable than the second one. But the more complex the query gets, the less readable the URL becomes anyway, even using your preferred "normal" solution. – a better oliver Nov 16 '15 at 19:17
  • Oh. I completely agree that JSON should be in the body. And I'd love to put it there, but GET with body is not yet (widely?) supported. Or at least I haven't managed to send a GET with body in jQuery, or vanilla js, or any rest browser plugin that I use. I'd love to do something like elastic search did, but I don't control the client. And I don't like the idea of sending a post instead of a get, if i can get around it. – Ana F Nov 17 '15 at 11:03

1 Answers1

1

Loopback provides a REST interface for your models, with the ability to carry out quite complex queries against the data without any additional coding required. I think they have modelled the syntax on the OData standard. So that is why the querystring is more complex than you might expect.

In Loopback you can create your own, custom end points by using Remote Methods, so you could create and expose an endpoint like getuser which took in the parameters you specified, resulting in a much simpler API.

conradj
  • 2,481
  • 2
  • 24
  • 30
  • I think performing database query through query string in just to check if our logic works or not. And then can create custom rest endpoint through remote method that will store the logic. This way you hide the logic and can provide simple rest endpoint. Because normal query string can't tell loopback what to do with the arguments (for less than or other complex comparision). – xangy Nov 17 '15 at 14:53