client: Verify path parameters are non-empty before sending request

[bmoylan]

@ungureanuvladvictor had an issue that was hard to debug where a generated client was receiving 404s because a path parameter was provided as the empty string to a path like /service/api/path/{param} so it rendered as /service/api/path/

Possible solution: Add a precondition before sending a request that all path parameters are non-empty.

@iamdanfox @ferozco does Java deal with this? Any edge cases where empty would be correct?

cc @nmiyake

[nmiyake]

Thanks for flagging -- yes, I can't think of a condition in which an empty path parameter value would be valid, so think that performing runtime validation on the client side (before request is even sent) makes sense.

[ferozco]

The verifier actually has a test case to ensure clients/servers support empty path parameters however it does not exercise the case where a trailing path param disambiguate two different endpoints

[nmiyake]

@ferozco can you clarify a few things?

First, in the general case, is it considered valid for a path segment that is not the final one to be empty? If we have foo/{bar}/baz as a path, is foo//baz valid?

If we're okay with the final segment only being empty, that does work. However, as you point out, it means that if there's another endpoint with everything the same except the final path parameter, than the final parameter will never be able to have the empty value (since Conjure matching rules say the longest literal match should be matched first).

[ferozco]

First, in the general case, is it considered valid for a path segment that is not the final one to be empty? If we have foo/{bar}/baz as a path, is foo//baz valid?

Yes, its valid for a segment to be empty.

I don't think we've ever hit the edge case where there are a pair of endpoints that are only disambiguated by a trailing path parameter and where it is expected/valid for that path param to be empty. I'd push a bit and say that the combination of factors is probably indicative of an issue with the design of the API