I’m involved in development of a group of web services which will have REST interfaces. Some of them are being converted from SOAP; others will be implemented for the first time with REST.
In one of the SOAP APIs, many request messages contain complextype elements with maxOccurs=“unbounded”. (Think: arrays with indefinite numbers of elements.) I’ve seen a proposed REST design which implements these elements with repeating query string parameters. For example, if part of a SOAP message looked like this:
<finish>semigloss</finish>
<colors>
<color>blue</color>
<color>green</color>
<color>grey</color>
</colors>
The corresponding REST resource would be called like this:
GET whatever?finish=semigloss&color=blue&color=green&color=grey
I’m not sure what to make of this. The service in question is implemented in Java, and presumably the designer knows how to read repeating parameters in Java without undue pain. But our shop is expressly not committed to Java for all of its future API development, and I wonder how this will play out in other languages.
In PHP, the only language in which I’ve done web development, this simply won’t work. Parameters are passed in an associative (key/value) array; two parameters with the same name are the same parameter, by definition, and only one value is passed. To handle repeated parameters, each PHP script would have to ignore PHP’s standard mechanism for parameter passing and parse the raw query string itself.
If you have web development experience in several languages, what do you think of APIs that use repeating parameters? Is this a perfectly reasonable design approach that PHP fumbles? Or is it an ill-considered notion that ought to be deep-sixed before someone takes it seriously?