Vote up to Idea Ignore unknown paramaters
Voting Disabled
Vote down to Idea Ignore unknown paramaters

Rank28

Idea#135

This idea is active.
API Technical Discussions »

Ignore unknown paramaters

the api should simply ignore any parameter it doesn't understand instead of throwing an error. For example jquery will append _=randomNumber to prevent caching of jsonp by the browser. This feature breaks that.

Submitted by calvin.metcalf 1 year ago

Vote Activity Show

Events

  1. The idea was posted
    1 year ago

Comments (8)

  1. There may be a technical reason behind it, however this does sound like a good idea.

    1 year ago
    0 Agreed
    0 Disagreed
  2. Calvin,

    Thank you for your feedback. In general, silently ignoring errors tends to be a bad thing. We chose to make the API explicitly check every parameter because it can be very helpful in catching bugs. For example, if one assumes the name of the JSONP callback parameter is "callback" then, with the current implementation, an API user will immediately be told that there is an error in his query string. However, if we did not explicitly check every parameter then the user would not receive a error and he would be left scratching his head, trying to determine why there is no JSON padding/prefix in the result.

    With respect to jQuery inserting a random parameter into the query string, is there a way to disable that functionality? We control client-side caching via HTTP headers and, frankly, we don't want that caching to be effectively disabled by an additional, random parameter.

    1 year ago
    0 Agreed
    0 Disagreed
  3. calvin.metcalf Idea Submitter

    So I'm going to disagree on that one as if there isn't padding the error message doesn't actually tell me anything I wouldn't figure out because I'd need to go to the documentation to find out what the correct callback was anyway.

    The chances the api throwing an error when it doesn't recognize something is much more likely to cause issues then to solve any issues. It's usually considered good practise for REST APIs to assume any extra parameters are for someone else along the line.

    As for caching in jQuery I believe this is a feature you want as scripts (like jsonp) tend to be much more aggressively cached then regular ajax requests, it doesn't actually effect you because you have to set queue:false in order to access the api through jQuery, I'd suggest mentioning it in the docs if you don't fix it because I'm guessing a huge chunk of web people are going to be using jQuery to access this api.

    1 year ago
    0 Agreed
    0 Disagreed
  4. calvin.metcalf Idea Submitter

    It occurs to me that some APIs have a stricy=true or mode= pedantic for situations like what you described.

    1 year ago
    0 Agreed
    0 Disagreed
  5. The assumption that the parameters are for anything other then us is faulty. We already know where the query is going, and we are parsing it out as needed, extra parameters would show that someone/thing simply doesn't understand the interface. Throwing an error in that case is the best option because if we assumed that the query was otherwise valid we could end up returning numbers that are not what was intended.

    Some examples:

    Some datasets allow for pivots, suppose a query looks like this:

    get=TOTALPOP&pivot=TIME&for=state:01

    Pivot is unrecognized and would therefore be ignored under your system. This changes the number that is returned, the developer may never be aware that this query is not providing the correct result until their customer complains.

    Perhaps while using a dataset where geography is not required, a query is created along these lines:

    get=TOTALPOP&fro=state:01

    As far as the api is concerned "fro" is not "for" and therefore ignored, returning total population of the dataset as a whole, again one number is expected, and one number is returned.

    Perhaps universe restrictions, which are not currently used by any dataset:

    agegrp=1&gendre=1 where gender is spelled wrong, and subsequently ignored. This would suddenly return more results then you would otherwise expect. Additional required variables would simply confuse the issue.

    Additionally I would like your input on the following example:

    A dataset where geography is required, but provided the above query string where for is misspelled, should we throw an error at this point? The data requires there to be a geography component, and cannot be properly tabulated without it.

    1 year ago
    0 Agreed
    0 Disagreed
  6. calvin.metcalf Idea Submitter

    So most other APIs I've used are built with the 'Robustness Principle' in mind (http://tools.ietf.org/html/rfc1122#page-12) because the situations I was thinking of are more along the lines of how jQuery by default adds a dummy parameter to some queries (an underscore) and I would not be surprised if there were proxies and such that did similar things, or if someone wanted to create a mash up which had it's own fields, or you wanted to depreciate a field that didn't do anything or something. If you try to prevent users from making error that direction lies madness, especially because you can do nothing for the user that simply puts in an incorrect but valid value in a field. A good method would be to just ignore any field that isn't recognized, it'd still give errors if required fields were missing or fields were used in illegal combinations.

    1 year ago
    0 Agreed
    0 Disagreed
  7. I don't quite understand why an individual would ask our api for fields they know don't exist according to our developers page. A place you need to visit to get your key to work with the api.

    1 year ago
    0 Agreed
    0 Disagreed
  8. Moderator

    calvin, thanks for the pointers.

    1 year ago
    0 Agreed
    0 Disagreed