Always prefix identifiers in path for consistency

[qvwonterghem]

Currently, in the REST guidelines : path parameter: use id or code, OPTIONALLY prefixed with the resource type to disambiguate when there are multiple identifiers as path parameters

I propose to remove the OPTIONALLY and always prefix the id or code in the path. Even if there is no ambiguity in the resource -> That way we are consistent across all API -> If a child resource is added in a later version, it won't need to be renamed

[pvdbosch]

WG agrees with proposal.

example:

/meetings/{id}/invitees/{inviteeId}
/meetings/{meetingId}/invitees/{inviteeId}  => this is the new recommendation

renaming path parameters doesn't have impact on runtime backwards-compatibility (over-the-wire remains the same)

rest-guide-validator: warn if only "id" or "code" - no validation otherwise bc lots of business identifier names are accepted as well (e.g. ssin, enterpriseNumber)

[jpraet]

renaming path parameters doesn't have impact on runtime backwards-compatibility (over-the-wire remains the same)

There is a small potential impact on problems that reference the path parameter name in in/name/value. In the rest-problem library it also impacted the detail message for 404 Resource Not Found, but I made a PR to improve that.