Open Graham42 opened 10 years ago
I think that we can leave this for later. I see no reason why we can't use this method until later when we can change to using a comma separated list. If we built everything correctly we should only need to touch the field limiter. On 2013-12-19 3:18 PM, "Graham42" notifications@github.com wrote:
The FieldLimiter should take the field parameter as a list like ?fields=fieldA,fieldB,fieldC and not ?field=fieldA&field=fieldB&field=fieldC the way it currently does.
I will can work on this when I get chance.
— Reply to this email directly or view it on GitHubhttps://github.com/Queens-Hacks/qcumber-api/issues/17 .
We should accept both, but I think the current ?key=val1&key=val2
is more important.
So my understanding is that there's no standard to guide us here, just conventions.
?key=val1&key=val2
This is how web browsers encode values for a multi-select list, and it seems to be widely supported. Werkzeug has built-in support for for this. (side-note: wikipedia claims that servers should accept semicolons instead of spaces, but werkzeug doesn't seem to) jQuery also follows this convention when you try to serialize an array (http://api.jquery.com/jQuery.param/). Finally, python's built-in urllib.urlencode
will also serialize lists this way (you have to pass doseq=1
or it just stringifies it).
I think this one is closer to a standard.
?key=val1,val2
There isn't a really standard convention here, but I think sticking to just a comma-delimited list is simple and obvious. Apigee cites some big apis, like facebook, linkedin, google, that do this or some close variation, and apigee recommends it.
It's also way nicer to type into a browser, and if you don't have a library at hand to serialize your array into a query, joining on ,
is pretty easy.
The FieldLimiter should take the field parameter as a list like
?fields=fieldA,fieldB,fieldC
and not?field=fieldA&field=fieldB&field=fieldC
the way it currently does.I will can work on this when I get chance.