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 and weight.
Actually my resource was designed to have an incremental ID generated by database, but this approach is not so good to API consumers, for example if a consumer/partner needs to update a freight info they have to do:
GET freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}
The response of the operation above would be the freight ID, so finally they can update the info:
PUT freight/{ID}
The partner ID is implicit by the authentication mechanism.
For me it seems strange force the partners to obtain the freight ID before update the info.
So my question is: how can I design this URI?
PUT freight/initialZipcode/{VALUE}/finalZipCode/{VALUE}/weight/{VALUE}
Have I to consider the design above?
Another question: is a good practice to embedded the partnerId in authentication mechanism? I know the pros (easy to consumers) and cons (cache, impossibility to share an URI, etc), but I don't know if generally is a good or bad practice.
Thanks!