Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify Query Param Complexity #61

Open
pop opened this issue Feb 16, 2016 · 1 comment
Open

Simplify Query Param Complexity #61

pop opened this issue Feb 16, 2016 · 1 comment

Comments

@pop
Copy link
Contributor

pop commented Feb 16, 2016

In a discussion with @mathuin and @Kennric we came to the conclusion that our query parameters allow for overly complex (and perhaps even malicious) queries to occur. This makes our lives harder in that we have to implement / maintain / test conceptually straining.

To help solve some of our problems we are going to simplify the query parameters by restricting use of only one of each type of query parameter in a given request. If more than one of the same query parameter is sent it will be discarded.

This results in a query who's maximum length is this:

GET /times?\
     include_revisions=<bool>\
    &include_deleted=<bool>\
    &user=<username>\
    &project=<project>\
    &activity=<activity>\
    &start=<date>\
    &end=<date>

... which puts more strain on any system that uses our API (in that it has to make multiple calls to get, say times for multiple users) but makes the API itself quite a bit easier to implement and test, and hopefully adds the benefit of freeing up resources instead of encouraging bundled mega-requests ("I want the times from all 5000 of these individual employees please").

@Kennric @matthewrsj @LyonesGamer @athai thoughts?

We could further limit the use of these parameters, but the guiding principles here are as follows:

  • All boolean flags increase the size of your response.
  • All non-boolean flags filter the size of your response.

If we like that I can document it and work on implementation. Otherwise let's discuss.

@matthewrsj
Copy link
Contributor

I'm fine with this. I don't think this adds complexity from client side, in fact it removes complexity for pymesync. It might add the need for a loop on front-end, but that is a non-issue. This also removes the need for in-line errors suggested in #57

@MorganEPatch MorganEPatch changed the title Simplify Query Pram Complexity Simplify Query Param Complexity Mar 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants