[OTDev] API change - drop [] from query strings - what do you think?

Christoph Helma helma at in-silico.ch
Fri Nov 12 14:46:39 CET 2010


Dear all,

Our middleware (Rack, http://rack.rubyforge.org/) seems to expect
brackets for parameter lists - if they are omitted only the last value
is read. I would prefer not having to mess around with Racks internals. 

Best regards,
Christoph


Excerpts from chung's message of Mon Nov 08 22:43:30 +0100 2010:
> Hi Nina, Tobias, All,
>  
>   Do you suggest to drop the brackets just from the URL parameters (e.g.
> http://something.com/?params[]=... ) or in general for POSTed
> parameters. Let me remind that some services such as our filtering
> service and the consensus modeling algorithm (under construction)
> require arrays of data. I have sent already an email describing how can
> we handle arrays of parameters traveling over HTTP as well as their
> representation in RDF (and we have already started coding).
> 
> Best regards,
> Pantelis
> 
> On Mon, 2010-11-08 at 18:23 +0200, Nina Jeliazkova wrote:
> 
> > Hello All ,
> > 
> > I would like to propose to drop square brackets from query parameter names
> > throughout OpenTox API , e.g. parameters like feature_uris[] to become
> > feature_uris.
> > 
> > The reasons are
> > 
> > 1) Some implementations (rightly) URL encode the parameter names in URL
> > query string, however, this is not correctly understood by all clients.
> > 
> > http://localhost:8181/dataset/1?feature_uris%5B%5D=http%3A%2F%2Flocalhost%3A8181%2Ffeature%2F3
> > 
> > 2) Not sure what was the original idea behind [] , but they don't really
> > impose any control on how many instances of particular parameter should be
> > there, so it's more of a syntax headache.
> > 
> > 3) Finally, parameters like ?feature_uris%5B%5D=..  are not quite readable,
> > even if interpreted correctly.
> > 
> > What do you think?
> > 
> > Nina
> > _______________________________________________
> > Development mailing list
> > Development at opentox.org
> > http://www.opentox.org/mailman/listinfo/development
> > 
> 



More information about the Development mailing list