I have a question about how design a resource URI with composite keys.
I have a resource called freight that has 4 keys/ids: partner ID, initial zipcode, final zipcode a
There is nothing wrong with
PUT freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}
Query parameters are part of the resource identification too.
Path parameters are useful for defining resources that fit nicely in a hierarchy. In your case the resource doesn't fit well in a hierarchy, so don't try and squeeze the parameters into path segments.
The only challenge is what to do when the client re-arranges the order of the query params. Do you you treat it as the same resource, or do you 404? If you are not caching the GET responses then it probably doesn't matter.
If you provided your client with a URI template for them to fill in then there is less chance that they will give you the params in the wrong order.
The other option, if you go with your original suggestion is that your GET returns a redirect and a Location header to a URI with the freight ID. e.g.
GET freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}
=>
302 See Other
Location: freight/1232321322
By doing this, your client doesn't have to know anything about the freight ID, it can just grab the location header, and follow the redirect to do a GET, or do a PUT directly against whatever URI is in the Location header. This means that if you decide you don't like exposing the ID in the future, you can change the URI without breaking any clients.