How to deal with duplicate properties in a urlencoded string when they are NOT "Back-to-Back"?

Hey socaltester 

Ok - you've given good points -ok - here's my opinion on what you've stated - my comment is in BLUE text

Step 1: "in Resource or in Method, add parameter (use style = QUERY)" = Is fairly straight forward. I'm choosing "Method", but perhaps I should choose "Resource"? - RichComment: shouldn't make any difference whether it's Method or Resourcce level - I just created an example where 1 repeating QueryParm attribute is Method level and 1 repeating QueryParm attribute is Resource and the request works fine.

Step 2: "select parameter and enable "Disable Encoding" at bottom of page" = Is fairly clear. Does this need to be done with each duplicate. Also, how does SoapUI know where to insert each duplicate property within the urlencoded string (see Step 5). - RichComment: yes you need to disable the % encoding for each query parm that will be repeated in your request.  Regarding Step5 - SoapUI (more importantly you're endpoint) doesn't care about the sequence in which the query parms are built into the URI string of your request - so it doesn't matter what order they appear in - you could have ?name=A&name=B&name=C&colour=red&colour=blue=colour=green should be handled by your endpoint in the same manner if the URI string was ?name=A&colour=red&name=B&colour=blue&name=C&colour=green or any combination of these at all

Step 3: "in Request, select parameter and set Multi-Value Delimiter to \| in bottom-left properties section" = Is clear with backslash pipe (\|) RichComment: I actually didn't think this was that clear! (proves everyone's different!)

Step 4: "Set a value of, e.g., 1|2|3 for the parameter (can use DataGen)" = Is not clear on whether DataGen is needed and under what circumstances.  RichComment: - yeah I agree - when I saw your original post that included the instructions it took me about 10mins to set it up cos I wasn't clear what this meant at first - I think it would probably help.  You can parameterise the Value field to source values from a DataGen datasource step - so rather than hardcoding '1|2|3' - you could specify ${Datasource#FileContents} | {Datasource#FileContents} | ${Datasource#FileContents}' or the DataGen equivalent I'm guessing - I don't DataGen - but parameterisation is standard across SoapUI so I'd expect it work for all variations of this.

Step 5: "Request will be sent out with, e.g., parameter=1&parameter=2&parameter=3" - Is a clear example of duplicate properties of the same exact name being used "back-to-back", but not for one where duplicate properties are spread throughout a string where they're separated by other properties. Also, SoapUI does not allow duplicate property entries (see attached screenshot) of the exact same name. It also does not mention whether duplicate properties, after the initial one, need to have a character in its name be replaced with a HTML Hex Code or not. For example, REMARKS, REM%41RKS.  RichComment: ok - you have multiple issues in this last.  Firstly - as I state above REST rules indicate the sequence of query parameters shouldn't make any difference unless the developers haven't coded the endpoint correctly - hence I'm guessing this is the reason SoapUI doesn't care about the sequence of query parameters in your request.  Another way of looking at this - a REST request is equivalent to a database operation - e.g. HTTP POST can be equivalent to an SQL insert/update/upsert operation, HTTP GET is equivalent to a SELECT and if you think about an SQL SELECT statement - the attributes you define as required as present in your resultset or the attributes you define in your query filter can be in ANY order - hence it makes sense that an HTTP GET which does the same thing would have equivalent rules as the GET is subsequently changed to SQL via JDBC/ODBC (or whatever) when it hits the underlying database.

Secondly - you are correct in a certain way - ReadyAPI!/SoapUI doesn't support adding multiple identical query parameters in the QueryParm list.  HOWEVER - if you need to have multiple identical query parms - the instructions to do this (e.g. |\ in multiline flag AND use a bar e.g. | separator on the values populating the query parm 'Value' field AND disable the URL encoding) enable you to add create a request with multiple query parms - it appears that SoapUI translates each value AFTER the | as another instance of the repeating query parm - try it out - add in '1|2|3' for a single query parm (that you intend to repeat 3 times in your request) and you will see 3 instances of the query parameter added to the 'Parameters' field at the top of the screen (adjacent to the 'Resource' field).  If you remove the '3' from '1|2|3' so it reads '1|2|' - the 3rd repeated query parm is REMOVED from the 'Parameters' field.  NOTE: the bar delimited values you specify in your Query Parms 'Value' field cannot include SPACE characters - so it cannot read for example '1 | 2 | 3' - it should be '1|2|3' - otherwise you will get an illegal character warning cos you've disabled the URL encoding. 

Thirdly - you mention that the instructions don't mention "whether duplicate properties, after the initial one, need to have a character in its name be replaced with a HTML Hex Code or not. For example, REMARKS, REM%41RKS".  I don't know why you think this is necessary - yes any HTTP request is typically percent (URL) encoded - but only partial encoding is typically enforced (so all non letter and number characters are % encoded (essentially all reserved characters (£$%^&* etc.) need % encoding.  NOTE: despite the fact the URL encoding checkbox label reads 'Disables URL-encoding of the parameter value' - the checkbox does actually disable the encoding on the Query Parm Name as well. 

Screenshot of a request with 2 duplicate attributes (name and colour) that works on my machine is below - hopefully this will help!

Nice one!

Rich